Internet Engineering Task Force G. Bertrand, Ed.
Internet-Draft E. Stephan
Intended status: Informational France Telecom - Orange
Expires: March 25, 2012 G. Watson
T. Burbridge
P. Eardley
BT
K. Ma
Azuki Systems
September 22, 2011
Use Cases for Content Delivery Network Interconnection
draft-ietf-cdni-use-cases-00
Abstract
Content Delivery Networks (CDNs) are commonly used for improving the
footprint and the end-user experience of a content delivery service,
at a reasonable cost. This document outlines real world use-cases
(not technical solutions) for interconnecting CDNs. It can be used
to provide guidance to the CDNI WG about the interconnection
arrangements to be supported and to validate the requirements of the
various CDNI interfaces.
This document describes a number of use cases that motivate CDN
Interconnection. It represents a work in progress and may be
extended later to cover additional use-cases.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
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 March 25, 2012.
Copyright Notice
Bertrand, et al. Expires March 25, 2012 [Page 1]
Internet-Draft CDNI Use Cases September 2011
Copyright (c) 2011 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.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Bertrand, et al. Expires March 25, 2012 [Page 2]
Internet-Draft CDNI Use Cases September 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Rationale for Multi-CDN Systems . . . . . . . . . . . . . 5
1.4. The Need for CDNI Standards . . . . . . . . . . . . . . . 7
2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 7
2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 7
2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 8
2.3. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 8
3. Offload Use Cases . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Overload Handling and Dimensioning . . . . . . . . . . . . 8
3.2. Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Failure of Content Delivery Resources . . . . . . . . 9
3.2.2. Failure of Content Acquisition . . . . . . . . . . . . 9
4. CDN Capability Use Cases . . . . . . . . . . . . . . . . . . . 9
4.1. Device and Network Technology Extension . . . . . . . . . 10
4.2. Technology and Vendor Interoperability . . . . . . . . . . 10
4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 11
5. Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Content Availability . . . . . . . . . . . . . . . . . . . 11
5.1.1. Geo-location Restrictions . . . . . . . . . . . . . . 11
5.1.2. Temporal Restrictions . . . . . . . . . . . . . . . . 12
5.1.3. Content Encoding Restrictions . . . . . . . . . . . . 12
5.2. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.3. Secure Access . . . . . . . . . . . . . . . . . . . . . . 13
6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Bertrand, et al. Expires March 25, 2012 [Page 3]
Internet-Draft CDNI Use Cases September 2011
1. Introduction
Content Delivery Networks (CDNs) are commonly used for improving the
footprint and the end-user experience of a content delivery service,
at a reasonable cost. This document outlines real world use-cases
(not technical solutions) for interconnecting CDNs. It can be used
to provide guidance to the CDNI WG about the interconnection
arrangements to be supported and to validate the requirements of the
various CDNI interfaces.
This document describes a number of use cases that motivate CDN
Interconnection. It represents a work in progress and may be
extended later to cover additional use-cases.
This document identifies the main motivations for a CDN Provider to
interconnect its CDN:
o CDN Footprint Extension Use Cases (Section 2)
o CDN Offload Use Cases (Section 3)
o CDN Capability Use Cases (Section 4)
Then, the document highlights the need for interoperability to
exchange and enforce content delivery policies (Section 5).
1.1. Terminology
We adopt the terminology described in
[I-D.ietf-cdni-problem-statement], [RFC3466], and [RFC3568], except
for the terms defined below.
Authoritative CDN (aCDN):
A CDN provider contracted by the CSP for delivery of content by its
CDN or by its downstream CDNs.
Access CDN:
A CDN that is connected to the end-user's access and has information
about the end-user's profile and access capabilities.
Delivering CDN:
The CDN that delivers the requested content asset to the end-user.
In particular, the delivering CDN can be an access CDN.
[Ed. Note: Definition of recursive and iterative request routing
Bertrand, et al. Expires March 25, 2012 [Page 4]
Internet-Draft CDNI Use Cases September 2011
should be added to [I-D.davie-cdni-framework].]
CDN Interconnection:
Relationship between two CDNs that enables a CDN to provide content
delivery services on behalf of another CDN. It relies on a set of
interfaces over which two CDNs communicate in order to achieve the
delivery of content to end-users by one CDN (the downstream CDN) on
behalf of another CDN (the upstream CDN).
CDN peering: A business relation between two CDN providers based on
one or more CDN Interconnections.
1.2. Abbreviations
[Ed. Note: List of abbreviations to be updated later]
o CSP: Content Service Provider
o dCDN: downstream CDN
o NSP: Network Service Provider
o QoE: Quality of Experience
o QoS: Quality of Service
o SLA: Service Level Agreement
o uCDN: upstream CDN
o UA: User Agent
o UE: User Equipment
o VoD: Video on Demand
o WiFi: Wireless Fidelity
1.3. Rationale for Multi-CDN Systems
Content Delivery Networks (CDNs) are used to deliver content because
they can:
o improve the experience for the End User; for instance delivery has
lower latency and better robustness,
Bertrand, et al. Expires March 25, 2012 [Page 5]
Internet-Draft CDNI Use Cases September 2011
o reduce the operator's costs; for instance lower delivery cost
(reduced bandwidth usage) for cacheable content,
o reduce the Content Service Provider costs, such as datacenter
capacity, space, and electricity consumption.
Indeed, many network service providers and enterprise service
providers are deploying or have deployed their own CDNs. Despite the
potential benefits of interconnecting CDNs, today each CDN is a
standalone network. The objective of CDN interconnection is to
overcome this restriction: the interconnected CDNs should be able to
collectively behave as a single delivery infrastructure.
Let's take an example, as depicted in Figure 1. Two CDN Providers
establish a CDN Interconnection. The Content Service Provider CSP-1
reaches an agreement with CDN Provider A for the delivery of its
content. CDN Provider A and CDN Provider B agree to interconnect
their CDNs. When a User Agent that is connected to CDN Provider B's
network requests Content from CSP-1, the Content is actually
delivered from CDN-B, because handling of requests for CSP-1's
Content has been delegated as part of the CDN Interconnection
agreement. The End User benefits through a better quality of
experience, because the Content is delivered from a nearby Surrogate.
CDN Provider A benefits because it doesn't need to deploy such an
extensive CDN, whilst CDN Provider B receives some compensation for
the delivery. CSP-1 benefits because it only needs to make one
business agreement and one physical connection, with CDN Provider A,
but its End Users get a service quality as though CSP-1 had also gone
to the trouble of making a business agreement with CDN Provider B.
+-------+ +-------+
| CSP-1 | | CSP-2 |
+-------+ +-------+
| |
,--,--,--. ,--,--,--.
,-' `-. ,-' `-.
( CDN Provider A )=====( CDN Provider B )
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--'
|
+------------+
| User Agent |
+------------+
=== CDN Interconnection
Figure 1
Bertrand, et al. Expires March 25, 2012 [Page 6]
Internet-Draft CDNI Use Cases September 2011
To extend the example, another Content Service Provider, CSP-3, may
also reach an agreement with CDN Provider A. But it does not want its
Content to be distributed by CDN Provider B, for example, CSP-3 may
not have distribution rights in the country where CDN Provider B
operates. This example illustrates that policy considerations are an
important part of CDNI.
1.4. The Need for CDNI Standards
Existing CDN interfaces are proprietary and have often been designed
for intra-CDN/intra-domain operations. So an external CDN typically
cannot use them, especially if the two CDNs rely on different
implementations. Nevertheless, [I-D.bertrand-cdni-experiments] shows
that some level of CDN interconnection can be achieved experimentally
without standardized interfaces between the CDNs. However, the
methods used in these experiments are hardly usable in an operational
context, because they suffer from several limitations in terms of
functionalities, scalability, and security level.
The aim of IETF CDNI WG's solution is therefore to overcome such
shortcomings; a full list of requirements is being developed in
[I-D.ietf-cdni-requirements].
2. Footprint Extension Use Cases
Footprint extension is expected to be a major use case for CDN
interconnection.
2.1. Geographic Extension
In this use case, the CDN Provider wants to extend the geographic
distribution that it can offer to its CSPs:
o without compromising the quality of delivery,
o without incurring additional transit and other network costs that
would result from serving content from geographically or
topologically remote surrogates.
If there are several CDN Providers that have a geographically limited
footprint (e.g., restricted to one country), or do not serve all end-
users in a geographic area, then interconnecting their CDNs enables
CDN Providers to provide their services beyond their own footprint.
As an example, suppose a French CSP wants to distribute its TV
programs to End Users located in France and various countries in
North Africa. It asks a French CDN Provider to deliver the content.
Bertrand, et al. Expires March 25, 2012 [Page 7]
Internet-Draft CDNI Use Cases September 2011
The French CDN Provider's network only covers France, so it makes an
agreement with another CDN Provider that covers North Africa.
Overall, from the CSP's perspective the French CDN Provider provides
a CDN service for both France and North Africa.
In addition to video, this use case applies to other types of content
such as automatic software updates (browser updates, operating system
patches, virus database update, etc).
2.2. Inter-Affiliates Interconnection
In the previous section, we have described the case of geographic
extension between CDNs operated by different entities. A large CDN
Provider may also operate CDNs from several subsidiaries (which may
rely on different CDN solutions, see Section 4.2). In certain
circumstances, the CDN Provider needs to make its CDNs interoperate
to provide a consistent service to its customers on its whole
footprint.
2.3. Nomadic Users
In this scenario a CSP wishes to allow users who move to other
geographic regions to continue to access their content. The
motivation in this case is to allow nomadic users to maintain access
with consistent quality of experience, rather than to allow all
residents within a region access to the content.
[Ed. Note: expand on which CDNs need to be interconnected to address
the use case (ie with CDN of "home NSP" interconnected to CDN of
visited NSP). Add a picture for clarifying the text. Use the term
"TV everywhere"?]
This use case covers situations like users moving between different
CDN Providers within the same geographic region, or users switching
between different devices, as discussed in Section 4.
3. Offload Use Cases
3.1. Overload Handling and Dimensioning
A CDN is likely to be dimensioned to support the prime-time traffic.
However, unexpected spikes in content popularity may drive load
beyond the expected peak. The prime recurrent time peaks of content
distribution may differ between two CDNs. Taking advantage of the
different traffic peak times, a CDN may interconnect with another CDN
to increase its effective capacity during the peak of traffic. This
brings dimensioning savings to the CDNs as they can use the resources
Bertrand, et al. Expires March 25, 2012 [Page 8]
Internet-Draft CDNI Use Cases September 2011
of each other during their respective peaks of activity..
Offload also applies to planned situations where a CDN Provider needs
CDN capacities in a particular region during a short period of time.
For example, a CDN can offload traffic to another CDN during a
specific maintenance operation or for covering the distribution of a
special event. For instance, consider a TV-channel which has
exclusive distribution rights on a major event, such as a
celebrities' wedding, or a major sport competitions. The CDNs that
the TV-channel uses for delivering the content related to this event
are likely to experience a flash crowd during the event and to need
offloading traffic, while other CDNs will support a more usual
traffic load and be able to handle the offloaded traffic load.
3.2. Resiliency
3.2.1. Failure of Content Delivery Resources
It is important for CDNs to be able to guarantee service continuity
during partial failures (e.g., failure of some Surrogates). In
partial failure scenarios, a CDN Provider could redirect some
requests towards another CDN, which must be able to serve the
redirected requests or, depending on traffic management policies, to
forward these requests to the CSP's origin server.
3.2.2. Failure of Content Acquisition
Source content acquisition is typically handled in one of two ways:
o CDN origin, where a downstream CDN acquires content from an
upstream CDN, and the authoritative CDN acquires content from an
origin server of the CSP, or
o Other origin, where the CDNs acquire content directly from an
origin server outside the uCDN.
Resiliency may be required against failure to ingest content. If a
CDN is unable to retrieve the content, it may be that the CSP's
origin server is inaccessible to only this CDN, in which case
redirection of the end-users to an alternative CDN may circumvent the
problem. A CSP may also choose to specify one or more backup origin
servers.
4. CDN Capability Use Cases
Bertrand, et al. Expires March 25, 2012 [Page 9]
Internet-Draft CDNI Use Cases September 2011
4.1. Device and Network Technology Extension
In this use case, the CDN Provider may have the right geographic
footprint, but may wish to extend the supported range of devices and
User Agents or the range of supported delivery technologies. In this
case, a CDN Provider may interconnect with a CDN that offers
services:
o that its own CDN is not able to support or,
o that the CDN provider is not willing to provide.
The following examples illustrate this use case:
1. CDN-A cannot support a specific delivery protocol. For instance,
CDN-A may interconnect with CDN-B to serve a proportion of its
traffic that requires HTTPS. CDN-A may use CDN-B's footprint
(which may overlap with its own) to deliver HTTPS without needing
to deploy its own infrastructure. This case could also be true
of other formats, delivery protocols (RTMP, RTSP, etc.) and
features (specific forms of tokenization, per session encryption,
etc.).
2. CDN-A has footprint covering traditional fixed line broadband and
wants to extend coverage to mobile devices. In this case, CDN-A
may contract and interconnect with CDN-B who has both:
* physical footprint inside the mobile network,
* the ability to deliver content over a protocol that is
required by specific mobile devices and not supported by
CDN-A.
In this case also it may be that CDN-B provides other features
related to adapting the content.
These cases can apply to many CDN features that a given CDN provider
may not be able to support or not be willing to invest in, and thus,
that the CDN provider would delegate to another CDN.
4.2. Technology and Vendor Interoperability
A CDN Provider may deploy a new CDN to run alongside its existing
CDN, as a simple way of migrating its CDN service to a new
technology. A CDN Provider may have a multi-vendor strategy for its
CDN deployment. A CDN Provider may want to deploy a separate CDN for
a particular CSP or a specific network. In all these circumstances,
CDNI benefits the CDN Provider, as it simplifies or automates some
Bertrand, et al. Expires March 25, 2012 [Page 10]
Internet-Draft CDNI Use Cases September 2011
inter-CDN operations (e.g., migrating the request routing function
progressively).
4.3. QoE and QoS Improvement
Some CSPs are willing to pay a premium for enhanced delivery of
Content to their End Users. In some cases, even if the CDN Provider
could deliver the content to the end users, it cannot meet the CSP's
service level requirements. So, it makes a CDN Interconnection
agreement with another CDN Provider that can provide the expected
quality of experience to the end-user, for instance an Access CDN
able to deliver content from Surrogates located closer to the end-
user.
5. Policy Enforcement
For the interconnection use cases described in previous sections, the
delegation of content delivery may be dependent upon the ability to
delegate delivery policy enforcement as well. CSPs may rely on the
ability to place delivery restriction on sets of content, which are
provided by existing CDNs. While the ability to support these
features across interconnected CDNs is desirable, that may not always
be feasible. It is important to be able to detect or define when
these features cannot be enforced.
5.1. Content Availability
The content distribution policies that a CSP attaches to a content
asset depend on many criteria. For instance, distribution policies
for audiovisual content often combine:
o temporal constraints (e.g., available for 24 hours, available 28
days after DVD release, etc.),
o resolution-based constraints (e.g., high definition vs. standard
definition), and
o geolocation-based constraints (e.g., per country).
5.1.1. Geo-location Restrictions
"Geo-blocking" rules may specify:
o the geographic regions where content can be delivered from (i.e.
the location of the Surrogates), or
Bertrand, et al. Expires March 25, 2012 [Page 11]
Internet-Draft CDNI Use Cases September 2011
o geographic locations where content can be delivered to (i.e., the
location of the End Users).
If a default value of "geo-blocking rules not supported" is set, the
CSP may wish to deny all access to the content, or blacklist specific
dCDNs which lack support for these features.
5.1.2. Temporal Restrictions
Time-based rules may specify:
o an activation time (i.e., the time when the content should become
available for delivery),
o a deactivation time (i.e., time after which the content should no
longer be delivered), or
o an expiration time (i.e., the time at which the content files
should be expunged from all CDN storage).
If a default value of "time-based rules not supported" is set, the
CSP may wish to deny all access to the content, or blacklist specific
dCDNs which lack support for these features.
5.1.3. Content Encoding Restrictions
[Ed. Note: Section to be removed? reworded?]
Encoding-based rules may specify:
o a subset of encodings deliverable to specific devices,
o a subset of encodings deliverable though a specific NSP, or
o a subset of encodings deliverable to users based on a subscription
or quality of service levels.
[Ed. Note: FLF The first bullet only makes sense if the solution
supports transcoding/transrating, which I don't know if it will be
supported in Initial scope. The last bullet does not make sense to
me as we do not want the CDNs to be aware of any user subscription
levels (ie only CSP is aware of user subscription level)."]
If a default value of "encoding-based rules not supported" is set,
the CSP may wish to deny all access to the content, or blacklist
specific dCDNs which lack support for these features.
Bertrand, et al. Expires March 25, 2012 [Page 12]
Internet-Draft CDNI Use Cases September 2011
5.2. Branding
There are situations where one CDN Provider cannot or does not want
to operate all the functions of a uCDN, e.g., a CDN exchange, which
handles request routing (and possibly log retrieval) but delegates
all content delivery to the surrogates of other dCDNs. Preserving
the branding of the CSP throughout delivery is often important to the
CSP. CSPs may desire to offer content services under their own name,
even when the associated CDN service involves other CDSPs. The CSP
may request that the name of the CDSPs does not appear in the URLs
and may wish to specify a specific brand related tag to appear in the
URLs. Similarly, in offload situations, the uCDN might want to offer
CDN services under its own branding.
If a default value of "branding rules not supported" is set, the CSP
may wish to deny all access to the content, or blacklist specific
dCDNs which lack support for these features.
5.3. Secure Access
Many protocols exist for delivering content to End Users. CSPs may
often wish to dictate a specific protocol or set of protocols which
are acceptable for delivery of their content, especially in the case
where content protection or user authentication is required (e.g.,
must use HTTPS and not HTTP, or must use URL hashing, etc.).
If a default value of "secure access rules not supported" is set, the
CSP may wish to deny all access to the content, or blacklist specific
dCDNs which lack support for these features.
6. Open issues
The section about nomadic users must be clarified
The section about Content Encoding Restrictions requires a
discussion: must the CDN enforce such restrictions?
7. Contributors
[Ed. Note: long list of co-authors. As per current practice, you
would want to split that into "editors" and "contributors".]
The following people have strongly contributed to this
specification's content:
Bertrand, et al. Expires March 25, 2012 [Page 13]
Internet-Draft CDNI Use Cases September 2011
8. Acknowledgments
The authors would like to thank Kent Leung, Francois Le Faucheur and
Ben Niven-Jenkins for lively discussions, as well as for their
reviews and comments on the mailing list.
They also thank the contributors of the EU FP7 OCEAN and ETICS
projects for valuable inputs.
9. IANA Considerations
This memo includes no request to IANA.
10. Security Considerations
CDN Interconnection, as described in this document, has a wide
variety of security issues that should be considered. The security
issues fall into three general categories:
o CSP Trust: where the CSP may have negotiated service level
agreements for delivery quality of service with the uCDN, and/or
configured distribution policies (e.g., geo-restrictions,
availability windows, or other licensing restrictions), which it
assumes will be upheld by dCDNs to which the uCDN delegates
requests. Furthermore, billing and accounting information must be
aggregated from dCDNs with which the CSP may have no direct
business relationship. These situations where trust is delegated
must be handled in a secure fashion to ensure CSP confidence in
the CDN interconnection.
o Client Transparency: where the client device or application which
connects to the CDN must be able to interact with any dCDN using
its existing security and DRM protocols (e.g., cookies,
certificate-based authentication, custom DRM protocols, URL
signing algorithms, etc.) in a transparent fashion.
o CDN Infrastructure Protection: where the dCDNs must be able to
identify and validate delegated requests, in order to prevent
unauthorized use of the network and to be able to properly bill
for delivered content. A dCDN may not wish to advertise that it
has access to or is carrying content for the uCDN or CSP,
especially if that information may be used to enhance denial of
service attacks. In general, CDNI interfaces and protocols should
minimize overhead for dCDNs.
This document focuses on the motivational use cases for CDN
Bertrand, et al. Expires March 25, 2012 [Page 14]
Internet-Draft CDNI Use Cases September 2011
Interconnection, and does not analyze these threats in detail.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[I-D.bertrand-cdni-experiments]
Bertrand, G., Faucheur, F., and L. Peterson, "Content
Distribution Network Interconnection (CDNI) Experiments",
draft-bertrand-cdni-experiments-01 (work in progress),
August 2011.
[I-D.davie-cdni-framework]
Davie, B. and L. Peterson, "Framework for CDN
Interconnection", draft-davie-cdni-framework-00 (work in
progress), July 2011.
[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-00 (work in
progress), September 2011.
[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements",
draft-ietf-cdni-requirements-00 (work in progress),
September 2011.
[I-D.ma-cdni-publisher-use-cases]
Nair, R. and K. Ma, "Content Distribution Network
Interconnection (CDNI) Publisher Use",
draft-ma-cdni-publisher-use-cases-00 (work in progress),
March 2011.
[I-D.watson-cdni-use-cases]
Watson, G., "CDN Interconnect Use Cases",
draft-watson-cdni-use-cases-00 (work in progress),
January 2011.
[RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
for Content Internetworking (CDI)", RFC 3466,
Bertrand, et al. Expires March 25, 2012 [Page 15]
Internet-Draft CDNI Use Cases September 2011
February 2003.
[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
Content Network (CN) Request-Routing Mechanisms",
RFC 3568, July 2003.
Authors' Addresses
Gilles Bertrand (editor)
France Telecom - Orange
38-40 rue du General Leclerc
Issy les Moulineaux, 92130
FR
Phone: +33 1 45 29 89 46
Email: gilles.bertrand@orange.com
Stephan Emile
France Telecom - Orange
2 avenue Pierre Marzin
Lannion F-22307
France
Email: emile.stephan@orange.com
Grant Watson
BT
pp GDC 1 PP14, Orion Building, Adastral Park, Martlesham
Ipswich, IP5 3RE
UK
Email: grant.watson@bt.com
Trevor Burbridge
BT
B54 Room 70, Adastral Park, Martlesham
Ipswich, IP5 3RE
UK
Email: trevor.burbridge@bt.com
Bertrand, et al. Expires March 25, 2012 [Page 16]
Internet-Draft CDNI Use Cases September 2011
Philip Eardley
BT
B54 Room 77, Adastral Park, Martlesham
Ipswich, IP5 3RE
UK
Email: philip.eardley@bt.com
Kevin Ma
Azuki Systems
43 Nagog Park
Acton, MA 01720
USA
Phone: +1 978 844 5100
Email: kevin.ma@azukisystems.com
Bertrand, et al. Expires March 25, 2012 [Page 17]
