Internet Engineering Task Force (IETF) G. Bertrand, Ed.
Request for Comments: 6770 E. Stephan
Obsoletes: 3570 France Telecom - Orange
Category: Informational T. Burbridge
ISSN: 2070-1721 P. Eardley
BT
K. Ma
Azuki Systems, Inc.
G. Watson
Alcatel-Lucent (Velocix)
November 2012
Internet Engineering Task Force (IETF) G. Bertrand, Ed.
Request for Comments: 6770 E. Stephan
Obsoletes: 3570 France Telecom - Orange
Category: Informational T. Burbridge
ISSN: 2070-1721 P. Eardley
BT
K. Ma
Azuki Systems, Inc.
G. Watson
Alcatel-Lucent (Velocix)
November 2012
Use Cases for Content Delivery Network Interconnection
内容交付网络互连的用例
Abstract
摘要
Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. This document can be used to motivate the definition of the requirements to be supported by CDN Interconnection (CDNI) interfaces. It obsoletes RFC 3570.
内容交付网络（CDN）通常用于改善内容交付服务的最终用户体验，同时将成本保持在合理水平。本文档重点关注与已确定的行业需求相对应的用例，这些用例在指定和实施支持CDN互连的开放接口和协议后有望实现。本文件可用于推动CDN互连（CDNI）接口支持的需求定义。它淘汰了RFC3570。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6770.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6770.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Rationale for CDN Interconnection . . . . . . . . . . . . 4
2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 6
2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 6
2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 6
2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 7
2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 7
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. Content Acquisition Resiliency . . . . . . . . . . . . 10
4. Capability Use Cases . . . . . . . . . . . . . . . . . . . . . 11
4.1. Device and Network Technology Extension . . . . . . . . . 11
4.2. Technology and Vendor Interoperability . . . . . . . . . . 12
4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12
5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Content Service Providers' Delivery Policies . . . . 14
A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 14
A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15
A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Rationale for CDN Interconnection . . . . . . . . . . . . 4
2. Footprint Extension Use Cases . . . . . . . . . . . . . . . . 6
2.1. Geographic Extension . . . . . . . . . . . . . . . . . . . 6
2.2. Inter-Affiliates Interconnection . . . . . . . . . . . . . 6
2.3. ISP Handling of Third-Party Content . . . . . . . . . . . 7
2.4. Nomadic Users . . . . . . . . . . . . . . . . . . . . . . 7
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. Content Acquisition Resiliency . . . . . . . . . . . . 10
4. Capability Use Cases . . . . . . . . . . . . . . . . . . . . . 11
4.1. Device and Network Technology Extension . . . . . . . . . 11
4.2. Technology and Vendor Interoperability . . . . . . . . . . 12
4.3. QoE and QoS Improvement . . . . . . . . . . . . . . . . . 12
5. Enforcement of Content Delivery Policy . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Content Service Providers' Delivery Policies . . . . 14
A.1. Content Delivery Policy Enforcement . . . . . . . . . . . 14
A.2. Secure Access . . . . . . . . . . . . . . . . . . . . . . 15
A.3. Branding . . . . . . . . . . . . . . . . . . . . . . . . . 15
Content Delivery Networks (CDNs) are commonly used for improving the End User experience of a content delivery service while keeping cost at a reasonable level. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once open interfaces and protocols supporting the interconnection of CDNs are specified and implemented. The document can be used to motivate the definition of the requirements (as documented in [CDNI-REQ]) to be supported by the set of CDN Interconnection (CDNI) interfaces defined in [RFC6707].
内容交付网络（CDN）通常用于改善内容交付服务的最终用户体验，同时将成本保持在合理水平。本文档重点关注与已确定的行业需求相对应的用例，这些用例在指定和实施支持CDN互连的开放接口和协议后有望实现。本文件可用于推动需求的定义（如[CDNI-REQ]中所述），以得到[RFC6707]中定义的CDN互连（CDNI）接口集的支持。
[RFC3570] describes slightly different terminologies and models for "Content Internetworking (CDI)". This document obsoletes RFC 3570 to avoid confusion.
[RFC3570]描述了与“内容互联（CDI）”略有不同的术语和模型。本文件淘汰RFC 3570以避免混淆。
This document identifies the main motivations for a CDN Provider to interconnect its CDN:
本文档确定了CDN提供商互连其CDN的主要动机：
o CDN Footprint Extension Use Cases (Section 2)
o CDN封装外形扩展用例（第2节）
o CDN Offload Use Cases (Section 3)
o CDN卸载用例（第3节）
o CDN Capability Use Cases (Section 4)
o CDN能力用例（第4节）
Then, the document highlights the need for interoperability in order to exchange and enforce content delivery policies (Section 5).
然后，本文档强调了为了交换和实施内容交付策略而需要的互操作性（第5节）。
In this document, the first letter of each CDNI-specific term is capitalized. We adopt the terminology described in [RFC6707].
在本文件中，每个CDNI特定术语的首字母大写。我们采用[RFC6707]中描述的术语。
We extend this terminology with the following term:
我们将该术语扩展为以下术语：
Access CDN:
访问CDN：
A CDN that includes Surrogates in the same administrative network as the End User. Such a CDN can use accurate information on the End User's network context to provide additional Content Delivery Services to Content Service Providers.
在与最终用户相同的管理网络中包含代理的CDN。这样的CDN可以使用关于最终用户的网络上下文的准确信息来向内容服务提供商提供额外的内容交付服务。
o CDN: Content Delivery Network, also known as Content Distribution Network
o CDN：内容交付网络，也称为内容分发网络
o CSP: Content Service Provider
o 内容服务提供商
o dCDN: downstream CDN
o dCDN：下游CDN
o DNS: Domain Name System
o 域名系统
o EU: End User
o 欧盟：最终用户
o ISP: Internet Service Provider
o 互联网服务提供商
o NSP: Network Service Provider
o 网络服务提供商
o QoE: Quality of Experience
o QoE：体验质量
o QoS: Quality of Service
o QoS：服务质量
o uCDN: upstream CDN
o uCDN：上游CDN
o URL: Uniform Resource Locator
o 统一资源定位器
o WiFi: Wireless local area network (WLAN) based on IEEE 802.11
o WiFi：基于IEEE 802.11的无线局域网（WLAN）
Content Delivery Networks (CDNs) are used to deliver content because they can:
内容交付网络（CDN）用于交付内容，因为它们可以：
o improve the experience for the End User; for instance delivery has lower latency (decreased round-trip-time and higher throughput between the user and the delivery server) and better robustness (ability to use multiple delivery servers),
o 改善最终用户的体验；例如，交付具有较低的延迟（减少了用户和交付服务器之间的往返时间和较高的吞吐量）和更好的健壮性（能够使用多个交付服务器），
o reduce the network operator's costs; for instance, lower delivery cost (reduced bandwidth usage) for cacheable content,
o 降低网络运营商的成本；例如，降低可缓存内容的交付成本（减少带宽使用），
o reduce the Content Service Provider's (CSP) internal infrastructure costs, such as data center capacity, space, and electricity consumption, as popular content is delivered externally through the CDN rather than through the CSP's own servers.
o 降低内容服务提供商（CSP）的内部基础设施成本，如数据中心容量、空间和电力消耗，因为流行内容是通过CDN而不是通过CSP自己的服务器从外部交付的。
Indeed, many Network Service Providers (NSPs) and Enterprise Service Providers are deploying or have deployed their own CDNs. Despite the potential benefits of interconnecting CDNs, today each CDN is a stand-alone 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.
事实上，许多网络服务提供商（NSP）和企业服务提供商正在部署或已经部署自己的CDN。尽管互连CDN具有潜在的好处，但如今每个CDN都是一个独立的网络。CDN互连的目标是克服这一限制；互连的CDN应该能够作为一个单一的交付基础设施共同运行。
An example is depicted in Figure 1, where two CDN Providers establish a CDN Interconnection. The Content Service Provider CSP-1 reaches an
图1中描述了一个示例，其中两个CDN提供商建立了CDN互连。内容服务提供商CSP-1到达
agreement with CDN Provider 'A' for the delivery of its content. Independently, CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.
与CDN提供商“A”就其内容的交付达成协议。CDN提供商“A”和CDN提供商“B”单独同意互连其CDN。
When a given User Agent requests content from CSP-1, CDN-A may consider that delivery by CDN-B is appropriate, for instance, because CDN-B is an Access CDN and the user is directly attached to it. Through the CDN Interconnection arrangements put in place between CDN-A and CDN-B (as a result of the CDN Interconnection agreement established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the request to CDN-B and the content is actually delivered to the User Agent by CDN-B.
当给定的用户代理请求来自CSP-1的内容时，CDN-A可以考虑CDN-B的传递是适当的，例如，因为CDN-B是接入CDN并且用户直接连接到它。通过CDN-A和CDN-B之间的CDN互连安排（由于CDN提供商“A”和CDN提供商“B”之间建立了CDN互连协议），CDN-A可以将请求重定向到CDN-B，内容实际上由CDN-B交付给用户代理。
The End User benefits from this arrangement through a better Quality of Experience (QoE, see [RFC6390]), because the content is delivered from a nearby Surrogate (e.g., lower latency, bottlenecks avoided). CDN Provider 'A' benefits because it does not need to deploy such an extensive CDN, while CDN Provider 'B' may receive some compensation for the delivery. CSP-1 benefits because it only needs to make one business agreement and one technical arrangement 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 and technical arrangement with CDN Provider 'B'.
最终用户通过更好的体验质量（QoE，请参见[RFC6390]）从这种安排中获益，因为内容是从附近的代理服务器交付的（例如，较低的延迟，避免了瓶颈）。CDN提供商“A”受益，因为它不需要部署如此广泛的CDN，而CDN提供商“B”可能会因交付而获得一些补偿。CSP-1的好处在于，它只需要与CDN提供商“A”签订一份业务协议和一份技术协议，但其最终用户可以获得服务质量，就好像CSP-1也遇到了与CDN提供商“B”签订业务协议和技术协议的麻烦一样。
+-------+ +-------+
| CSP-1 | | CSP-2 |
+-------+ +-------+
| |
,--,--,--./ ,--,--,--.
,-' `-. ,-' `-.
(CDN Provider 'A')=====(CDN Provider 'B')
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--'
|
+----------+
| End User |
+----------+
=== CDN Interconnection
+-------+ +-------+
| CSP-1 | | CSP-2 |
+-------+ +-------+
| |
,--,--,--./ ,--,--,--.
,-' `-. ,-' `-.
(CDN Provider 'A')=====(CDN Provider 'B')
`-. (CDN-A) ,-' `-. (CDN-B) ,-'
`--'--'--' `--'--'--'
|
+----------+
| End User |
+----------+
=== CDN Interconnection
Figure 1
图1
To extend the example, another Content Service Provider, CSP-2, may also reach an agreement with CDN Provider 'A'. However, CSP-2 may not want its content to be distributed by CDN Provider B; for example, CSP-2 may not want to distribute its content in the area where CDN Provider 'B' operates. This example illustrates that policy considerations are an important part of CDNI.
为了扩展该示例，另一个内容服务提供商CSP-2也可能与CDN提供商“A”达成协议。但是，CSP-2可能不希望其内容由CDN提供商B分发；例如，CSP-2可能不希望在CDN提供商“B”运营的地区分发其内容。这个例子说明了政策考虑是CDNI的一个重要部分。
Footprint extension is expected to be a major use case for CDN Interconnection.
封装外形扩展预计将成为CDN互连的主要用例。
In this use case, the CDN Provider wants to extend the geographic distribution that it can offer to its CSPs:
在本用例中，CDN提供商希望扩展其CSP可以提供的地理分布：
o without compromising the quality of delivery.
o 在不影响交付质量的情况下。
o without incurring additional transit and other network costs that would result from serving content from geographically or topologically remote Surrogates.
o 不会因从地理或拓扑上远程代理服务器提供内容而产生额外的传输和其他网络成本。
o without incurring the cost of deploying and operating Surrogates and the associated CDN infrastructure that may not be justified in the corresponding geographic region (e.g., because of relatively low delivery volume, or conversely because of the high investments that would be needed to satisfy the high volume).
o 无需承担在相应地理区域部署和运营代理和相关CDN基础设施的成本（例如，由于相对较低的交付量，或相反，由于满足较高的交付量所需的高投资）。
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 these CDN Providers to provide their services beyond their own footprint.
如果有多个CDN提供商的业务范围有限（例如，仅限于一个国家），或者无法为某个地理区域内的所有最终用户提供服务，则通过互连其CDN，这些CDN提供商可以提供超出其自身业务范围的服务。
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. 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.
例如，假设一家法国CSP希望将其电视节目分发给位于法国和北非各国的最终用户。它要求法国CDN提供商提供内容。法国CDN提供商的网络仅覆盖法国，因此它与另一家覆盖北非的CDN提供商达成协议。总的来说，从客户服务提供商的角度来看，法国CDN提供商为法国和北非提供CDN服务。
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.).
除视频外，此用例还适用于其他类型的内容，如自动软件更新（浏览器更新、操作系统补丁、病毒数据库更新等）。
The previous section describes the case of geographic extension between CDNs operated by different entities. A large CDN Provider may have several subsidiaries that each operate their own CDN (which may rely on different CDN technologies, see Section 4.2). In certain
上一节描述了不同实体运营的CDN之间的地理扩展情况。大型CDN提供商可能有多个子公司，每个子公司运营各自的CDN（可能依赖不同的CDN技术，请参见第4.2节）。一定
circumstances, the CDN Provider needs to make these CDNs interoperate to provide consistent service to its customers on the whole collective footprint.
在这种情况下，CDN提供商需要使这些CDN互操作，以便在整个范围内向其客户提供一致的服务。
Consider an ISP carrying to its subscribers a lot of content that comes from a third-party CSP and that is injected into the ISP's network by an Authoritative CDN Provider. There are mutual benefits to the ISP (acting as an Access CDN), the Authoritative CDN, and the CSP that would make a case for establishing a CDNI agreement. For example:
考虑一个ISP承载给它的用户很多来自第三方CSP的内容，并由权威的CDN提供商注入ISP的网络。ISP（作为接入CDN）、权威CDN和CSP之间存在互惠互利的关系，因此有理由建立CDNI协议。例如：
o allowing the CSP to offer improved QoE and QoE services to subscribers, for example, reduced content startup time or increased video quality and resolution of adaptive streaming content.
o 允许CSP向订户提供改进的QoE和QoE服务，例如，缩短内容启动时间或提高自适应流媒体内容的视频质量和分辨率。
o allowing the Authoritative CDN to reduce hardware capacity and footprint, by using the ISP caching and delivery capacity.
o 允许权威CDN通过使用ISP缓存和交付容量来减少硬件容量和占用空间。
o allowing the ISP to reduce traffic load on some segments of the network by caching inside of the ISP network.
o 允许ISP通过在ISP网络内部缓存来减少某些网段上的流量负载。
o allowing the ISP to influence and/or control the traffic ingress points.
o 允许ISP影响和/或控制流量入口点。
o allowing the ISP to derive some incremental revenue for transport of the traffic and to monetize QoE services.
o 允许ISP为流量传输获得一些增量收入，并将QoE服务货币化。
In this scenario, a CSP wishes to allow End Users who move between access networks to continue to access their content. The motivation of this case is to allow nomadic End Users to maintain access to content with a consistent QoE across a range of devices and/or geographic regions.
在此场景中，CSP希望允许在接入网络之间移动的最终用户继续访问其内容。本案例的动机是允许游牧最终用户在一系列设备和/或地理区域内以一致的QoE维护对内容的访问。
This use case covers situations like:
本用例涵盖以下情况：
o End Users moving between different access networks, which may be located within the same geographic region or different geographic regions.
o 在不同接入网络之间移动的终端用户，可能位于同一地理区域或不同地理区域内。
o End Users switching between different devices or delivery technologies, as discussed in Section 4.
o 最终用户在不同设备或交付技术之间切换，如第4节所述。
Consider the following example, illustrated in Figure 2: End User A has a subscription to a broadband service from ISP A, her "home ISP". ISP A hosts CDN-A. Ordinarily, when End User A accesses content via ISP A (her "home ISP"), the content is delivered from CDN-A, which in this example is within ISP A's network.
考虑下面的例子，如图2所示：终端用户A从ISP A订阅宽带服务，她的“家庭ISP”。ISP A托管CDN-A。通常，当最终用户A通过ISP A（其“家庭ISP”）访问内容时，内容从CDN-A传送，在本例中，CDN-A位于ISP A的网络内。
However, while End User A is not connected to ISP A's network, for example, because it is connected to a WiFi provider or mobile network, End User A can also access the same content. In this case, End User A may benefit from accessing the same content delivered by an alternate CDN (CDN-B), in this case, hosted in the network of the WiFi or mobile provider (ISP B), rather than from CDN-A in ISP A's network.
然而，当最终用户A未连接到ISP A的网络时，例如，因为它连接到WiFi提供商或移动网络，最终用户A也可以访问相同的内容。在这种情况下，最终用户A可以从访问由备用CDN（CDN-B）交付的相同内容中获益，在这种情况下，备用CDN（CDN-B）托管在WiFi或移动提供商（ISP B）的网络中，而不是从ISP A的网络中的CDN-A。
+-------+
|Content|
+-------+
|
,--,--,--. ,--,--,--.
,-' ISP A `-. ,-' ISP B `-.
( (CDN-A) )=====( (CDN-B) )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
| |
+------------+ +---------------+
+ EU A (home)| | EU A (nomadic)|
+------------+ +---------------+
=== CDN Interconnection
+-------+
|Content|
+-------+
|
,--,--,--. ,--,--,--.
,-' ISP A `-. ,-' ISP B `-.
( (CDN-A) )=====( (CDN-B) )
`-. ,-' `-. ,-'
`--'--'--' `--'--'--'
| |
+------------+ +---------------+
+ EU A (home)| | EU A (nomadic)|
+------------+ +---------------+
=== CDN Interconnection
Figure 2
图2
Though the content of CSP A is not accessible by typical End Users of CDN-B, End User A is able to gain access to her "home" content (i.e., the content of CSP A) through the alternate CDN (CDN-B).
虽然CDN-B的典型最终用户无法访问CSP A的内容，但最终用户A能够通过备用CDN（CDN-B）访问其“主页”内容（即CSP A的内容）。
Depending on the CSP's content delivery policies (see Appendix A.1), a user moving to a different geographic region may be subject to geo-blocking content delivery restrictions. In this case, he/she may not be allowed to access some pieces of content.
根据CSP的内容交付政策（见附录A.1），移动到不同地理区域的用户可能会受到地理阻止内容交付限制。在这种情况下，可能不允许他/她访问某些内容。
A CDN is likely to be dimensioned to support an expected maximum traffic load. However, unexpected spikes in content popularity (flash crowd) may drive load beyond the expected peak. The prime recurrent time peaks of content distribution may differ between two
CDN的尺寸可能会支持预期的最大流量负载。然而，内容受欢迎程度的意外峰值（flash群组）可能会导致负载超过预期峰值。两组间含量分布的主要重现时间峰值可能不同
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 each other's resources during their respective peaks of activity.
CDN。利用不同的业务高峰时间，CDN可以与另一CDN互连以在业务高峰期间增加其有效容量。这为CDN带来了尺寸节约，因为它们可以在各自的活动高峰期间使用彼此的资源。
Offload also applies to planned situations in which a CDN Provider needs CDN capacity in a particular region during a short period of time. For example, a CDN can offload traffic to another CDN for the duration of a specific maintenance operation or for the distribution of a special event, as in the scenario depicted in Figure 3. For instance, consider a TV channel that is the distributor for a major event, such as a celebrity's wedding or a major sport competition, and this TV channel has contracted particular CDNs for the delivery. The CDNs (CDN-A and CDN-B) that the TV channel uses for delivering the content related to this event are likely to experience a flash crowd during the event and will need to offload traffic, while other CDNs (CDN-C) will support a more typical traffic load and be able to handle the offloaded traffic.
卸载还适用于CDN提供商在短时间内需要特定区域CDN容量的计划情况。例如，一个CDN可以在一个特定维护操作期间或一个特殊事件的分发期间将流量卸载到另一个CDN，如图3所示。例如，考虑一个电视频道，这是一个重大事件的分销商，如名人的婚礼或大型体育比赛，并且这个电视频道已经签订了特定的CDN交付。电视频道用于传送与此事件相关的内容的CDN（CDN-A和CDN-B）在事件期间可能会遇到闪存拥挤，需要卸载流量，而其他CDN（CDN-C）将支持更典型的流量负载，并能够处理卸载的流量。
In this use case, the Delivering CDN on which requests are offloaded should be able to handle the offloaded requests. Therefore, the uCDN might require information on the dCDNs to be aware of the amount of traffic it can offload to each dCDN.
在此用例中，请求卸载的交付CDN应该能够处理卸载的请求。因此，uCDN可能需要dCDN上的信息来了解它可以卸载到每个dCDN的通信量。
+------------+
| TV Channel |
+------------+
| \
,-,--,-. \ ,-,--,-. ,-,--,-.
,' `. ,' `. ,' CDN-C `.
( CDN-A ) ( CDN-B )==( offload )
`. ,' `. ,' `. ,'
`-'--'-' `-'--'-' `-'--'-'
+------------+
| TV Channel |
+------------+
| \
,-,--,-. \ ,-,--,-. ,-,--,-.
,' `. ,' `. ,' CDN-C `.
( CDN-A ) ( CDN-B )==( offload )
`. ,' `. ,' `. ,'
`-'--'-' `-'--'-' `-'--'-'
=== CDN Interconnection
=== CDN Interconnection
Figure 3
图3
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 has at least three options:
CDN必须能够在部分故障（例如，某些代理故障）期间保证服务连续性。在部分故障情况下，CDN提供程序至少有三个选项：
1. if possible, use internal mechanisms to redirect traffic onto surviving equipment,
1. 如果可能，使用内部机制将流量重定向到幸存设备上，
2. depending on traffic management policies, forward some requests to the CSP's origin servers, and/or
2. 根据流量管理策略，将一些请求转发到CSP的源服务器，和/或
3. redirect some requests toward another CDN, which must be able to serve the redirected requests.
3. 将一些请求重定向到另一个CDN，该CDN必须能够为重定向的请求提供服务。
The last option is a use case for CDNI.
最后一个选项是CDNI的用例。
Source content acquisition may be handled in one of two ways:
可通过以下两种方式之一处理源内容获取：
o CSP origin, where a CDN acquires content directly from the CSP's origin server, or
o CSP源站，CDN直接从CSP的源站服务器获取内容，或
o CDN origin, where a downstream CDN acquires content from a Surrogate within an upstream CDN.
o CDN来源，其中下游CDN从上游CDN内的代理获取内容。
The ability to support content acquisition resiliency is an important use case for interconnected CDNs. When the content acquisition source fails, the CDN might switch to another content acquisition source. Similarly, when several content acquisition sources are available, a CDN might balance the load between these multiple sources.
支持内容获取弹性的能力是互连CDN的一个重要用例。当内容获取源出现故障时，CDN可能会切换到另一个内容获取源。类似地，当多个内容获取源可用时，CDN可能会平衡这些多个源之间的负载。
Though other server and/or DNS load-balancing techniques may be employed in the network, interconnected CDNs may have a better understanding of origin-server availability, and be better equipped to both distribute load between origin servers and attempt content acquisition from alternate content sources when acquisition failures occur. When normal content acquisition fails, a CDN may need to try other content source options, for example:
尽管网络中可以采用其他服务器和/或DNS负载平衡技术，但互连的CDN可以更好地了解源服务器的可用性，并且能够更好地在源服务器之间分配负载，并在发生捕获失败时尝试从备用内容源获取内容。当正常内容获取失败时，CDN可能需要尝试其他内容源选项，例如：
o an upstream CDN may acquire content from an alternate CSP origin server,
o 上游CDN可以从备用CSP源服务器获取内容，
o a downstream CDN may acquire content from an alternate Surrogate within an upstream CDN,
o 下游CDN可从上游CDN内的替代代理获取内容，
o a downstream CDN may acquire content from an alternate upstream CDN, or
o 下游CDN可从备选上游CDN获取内容，或
o a downstream CDN may acquire content directly from the CSP's origin server.
o 下游CDN可以直接从CSP的源服务器获取内容。
Though content acquisition protocols are beyond the scope of CDNI, the selection of content acquisition sources should be considered and facilitated.
虽然内容获取协议超出了CDNI的范围，但应考虑并促进内容获取源的选择。
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 supported range of delivery technologies. In this case, a CDN Provider may interconnect with a CDN that offers services that:
在这种情况下，CDN提供商可能具有正确的地理位置，但可能希望扩展设备和用户代理的支持范围或交付技术的支持范围。在这种情况下，CDN提供商可以与提供以下服务的CDN互连：
o the CDN Provider is not willing to provide, or
o CDN提供商不愿意提供，或
o its own CDN is not able to support.
o 它自己的CDN无法支持。
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 [RFC2818]. 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 (e.g., the Real Time Messaging Protocol (RTMP), the Real Time Streaming Protocol (RTSP), etc.), and features (specific forms of authorization such as tokens, per session encryption, etc.).
1. CDN-A无法支持特定的传递协议。例如，CDN-A可以与CDN-B互连，以满足其部分需要HTTPS的流量[RFC2818]。CDN-A可以使用CDN-B的足迹（可能与其重叠）来交付HTTPS，而无需部署自己的基础设施。这种情况也适用于其他格式、交付协议（例如，实时消息传递协议（RTMP）、实时流协议（RTSP）等）和功能（特定形式的授权，如令牌、每会话加密等）。
2. CDN-A has a 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:
2. CDN-A覆盖了传统的固定线路宽带，并希望将覆盖范围扩展到移动设备。在这种情况下，CDN-A可与CDN-B签订合同并互连，CDN-B同时拥有以下两项：
* a physical footprint inside the mobile network,
* 移动网络中的物理足迹，
* the ability to deliver content over a protocol that is required by specific mobile devices.
* 通过特定移动设备所需的协议交付内容的能力。
3. CDN-A only supports IPv4 within its infrastructure but wants to deliver content over IPv6. CDN-B supports both IPv4 and IPv6 within its infrastructure. CDN-A interconnects with CDN-B to serve out its content over native IPv6 connections.
3. CDN-A仅在其基础架构中支持IPv4，但希望通过IPv6交付内容。CDN-B在其基础架构中同时支持IPv4和IPv6。CDN-A与CDN-B互连，通过本机IPv6连接提供其内容。
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.
这些情况可以应用于许多CDN功能，这些功能可能是给定CDN提供商无法支持或不愿意投资的，因此CDN提供商将委托给另一个CDN。
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. In addition, a CDN Provider may have a multi-vendor strategy for its CDN deployment. Finally, 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 inter-CDN operations (e.g., migrating the request routing function progressively).
CDN提供商可以部署新的CDN与现有CDN一起运行，这是将其CDN服务迁移到新技术的一种简单方法。此外，CDN提供商可能有多供应商的CDN部署策略。最后，CDN提供商可能希望为特定CSP或特定网络部署单独的CDN。在所有这些情况下，CDNI使CDN提供商受益，因为它简化或自动化了一些CDN间的操作（例如，逐步迁移请求路由功能）。
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 would not meet the CSP's service-level requirements. As a result, the CDN Provider may establish a CDN Interconnection agreement with another CDN Provider that can provide the expected QoE to the End User, e.g., via an Access CDN that is able to deliver content from Surrogates located closer to the End User and with the required service level.
一些顾客服务提供商愿意为增强向最终用户交付内容而支付额外费用。在某些情况下，即使CDN提供商能够将内容交付给最终用户，也无法满足CSP的服务级别要求。结果，CDN提供商可以与另一CDN提供商建立CDN互连协议，该协议可以向最终用户提供预期的QoE，例如，通过能够从位于最终用户附近且具有所需服务级别的代理交付内容的接入CDN。
An important aspect common to all the above use cases is that CSPs typically want to enforce content delivery policies. A CSP may want to define content delivery policies that specify when, how, and/or to whom the CDN delivers content. These policies apply to all interconnected CDNs (uCDNs and dCDNs) in the same or similar way that a CSP can define content delivery policies for content delivered by a single, non-interconnected CDN. Appendix A provides examples of CSP-defined policies.
上述所有用例共有的一个重要方面是，CSP通常希望强制实施内容交付策略。CSP可能希望定义内容交付策略，以指定CDN何时、如何和/或向谁交付内容。这些策略适用于所有互连的CDN（UCDN和DCDN），其方式与CSP可以为单个非互连CDN交付的内容定义内容交付策略的方式相同或类似。附录A提供了CSP定义的策略示例。
The authors would like to thank Kent Leung, Francois Le Faucheur, Ben Niven-Jenkins, and Scott Wainner 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.
他们还感谢欧盟FP7海洋和ETICS项目的贡献者提供了宝贵的投入。
Finally, the authors acknowledge the work of the former CDI working group. This document obsoletes [RFC3570] to avoid confusion.
最后，作者感谢前CDI工作组的工作。本文件淘汰[RFC3570]以避免混淆。
This document focuses on the motivational use cases for CDN Interconnection and does not analyze the associated threats. Those threats are discussed in [RFC6707]. Appendix A.2 of this document provides example security policies that CSPs might impose on CDNs to mitigate the threats.
本文档侧重于CDN互连的激励性用例，不分析相关的威胁。[RFC6707]中讨论了这些威胁。本文件附录A.2提供了CSP可能对CDN实施的安全策略示例，以缓解威胁。
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012.
[RFC6707]Niven Jenkins，B.，Le Faucheur，F.，和N.Bitar，“内容分发网络互连（CDNI）问题声明”，RFC 67072012年9月。
[CDNI-REQ] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", Work in Progress, June 2012.
[CDNI-REQ]Leung，K.和Y.Lee，“内容分发网络互连（CDNI）要求”，正在进行的工作，2012年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC2818，2000年5月。
[RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003.
[RFC3570]Rzewski，P.，Day，M.，和D.Gilletti，“内容互联网（CDI）场景”，RFC 35702003年7月。
[RFC6390] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", BCP 170, RFC 6390, October 2011.
[RFC6390]Clark，A.和B.Claise，“考虑新性能指标开发的指南”，BCP 170，RFC 63902011年10月。
CSPs commonly apply different delivery policies to given sets of content assets delivered through CDNs. Interconnected CDNs need to support these policies. This appendix presents examples of CSPs' delivery policies and their consequences on CDNI operations.
CSP通常对通过CDN交付的给定内容资产集应用不同的交付策略。互联CDN需要支持这些政策。本附录提供了CSP交付政策的示例及其对CDNI运营的影响。
The content distribution policies that a CSP attaches to a content asset may depend on many criteria. For instance, distribution policies for audiovisual content often combine constraints of varying levels of complexity and sophistication, for example:
CSP附加到内容资产的内容分发策略可能取决于许多标准。例如，视听内容的分发策略通常结合了复杂程度和复杂程度不同的约束，例如：
o temporal constraints (e.g., available for 24 hours, available 28 days after DVD release, etc.),
o 时间限制（例如，24小时可用，DVD发行后28天可用等），
o user agent platform constraints (e.g., mobile device platforms, desktop computer platforms, set-top-box platforms, etc.),
o 用户代理平台约束（例如，移动设备平台、台式计算机平台、机顶盒平台等），
o resolution-based constraints (e.g., high definition vs. standard definition encodings),
o 基于分辨率的约束（例如，高清晰度与标准清晰度编码），
o user agent identification or authorization,
o 用户代理标识或授权，
o access network constraints (e.g., per NSP), and
o 接入网络限制（例如，每个NSP），以及
o IP geo-blocking constraints (e.g., for a given coverage area).
o IP地理阻塞约束（例如，对于给定的覆盖区域）。
CSPs may use sophisticated policies in accordance with their business model. However, the enforcement of those policies does not necessarily require that the delivery network understand the policy rationales or how policies apply to specific content assets. Content delivery policies may be distilled into simple rules that can be commonly enforced across all dCDNs. These rules may influence dCDN delegation and Surrogate selection decisions, for instance, to ensure that the specific rules (e.g., time-window, geo-blocking, pre-authorization validation) can indeed be enforced by the Delivering CDN. In turn, this can guarantee to the CSP that content delivery policies are properly applied.
客户服务提供商可以根据其业务模式使用复杂的策略。但是，这些策略的实施并不一定要求交付网络了解策略原理或策略如何应用于特定内容资产。内容交付策略可以提炼成简单的规则，这些规则通常可以在所有DCDN中强制实施。这些规则可能会影响dCDN委派和代理选择决策，例如，以确保特定规则（例如，时间窗口、地理阻止、预授权验证）确实可以由交付CDN实施。反过来，这可以向CSP保证内容交付策略得到正确应用。
+-----+
| CSP | Policies driven by business (e.g., available only
+-----+ in the UK and only from July 1st to September 1st)
\
\ Translate policies into
\simple rules (e.g., provide an authorization token)
\
V
+-----+
| CDN | Apply simple rules (e.g., check an
+-----+ authorization token and enforce geo-blocking)
\
\ Distribute simple rules
V
+-----+
| CDN | Apply simple rules
+-----+
+-----+
| CSP | Policies driven by business (e.g., available only
+-----+ in the UK and only from July 1st to September 1st)
\
\ Translate policies into
\simple rules (e.g., provide an authorization token)
\
V
+-----+
| CDN | Apply simple rules (e.g., check an
+-----+ authorization token and enforce geo-blocking)
\
\ Distribute simple rules
V
+-----+
| CDN | Apply simple rules
+-----+
Figure 4
图4
Many protocols exist for delivering content to End Users. CSPs may dictate a specific protocol or set of protocols that are acceptable for delivery of their content, especially in the case where a secured content transmission is required (e.g., must use HTTPS). CSPs may also perform a per-request authentication/authorization decision and then have the CDNs enforce that decision (e.g., must validate URL signing, etc.).
存在许多向最终用户交付内容的协议。CSP可以指定一个或一组可接受的特定协议来交付其内容，特别是在需要安全内容传输的情况下（例如，必须使用HTTPS）。CSP还可以执行每个请求的身份验证/授权决策，然后让CDN强制执行该决策（例如，必须验证URL签名等）。
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 CDN Providers. For instance, a CSP may desire to ensure that content is delivered with URIs appearing to the End Users under the CSP's own domain name, even when the content delivery involves separate CDN Providers. The CSP may wish to prevent the delivery of its content by specific dCDNs that lack support for such branding preservation features.
在整个交付过程中保持顾客服务提供商的品牌通常对顾客服务提供商很重要。CSP可能希望以自己的名义提供内容服务，即使相关CDN服务涉及其他CDN提供商。例如，即使内容交付涉及单独的CDN提供商，CSP也可能希望确保以CSP自己的域名向最终用户显示URI来交付内容。CSP可能希望阻止特定DCDN交付其内容，这些DCDN不支持此类品牌保护功能。
Analogous cases exist when the uCDN wants to offer CDN services under its own branding even if dCDNs are involved, and so it restricts the delivery delegation to a chain that preserves its brand visibility.
当uCDN希望在其自有品牌下提供CDN服务（即使涉及DCDN）时，也存在类似的情况，因此它将交付委托限制在保持其品牌知名度的链条上。
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
Gilles Bertrand（编辑）法国电信-Orange Leclerc Issy les Moulineaux将军街38-40号，92130 FR电话：+33 1 45 29 89 46电子邮件：Gilles。bertrand@orange.com
Stephan Emile France Telecom - Orange 2 avenue Pierre Marzin Lannion F-22307 FR EMail: emile.stephan@orange.com
Stephan Emile法国电信-橙2大道Pierre Marzin Lannion F-22307 FR电子邮件：Emile。stephan@orange.com
Trevor Burbridge BT B54 Room 70, Adastral Park, Martlesham Ipswich, IP5 3RE UK EMail: trevor.burbridge@bt.com
Trevor Burbridge BT B54，地址：英国IP5区Martlesham Ipswich Adastral公园70室，电子邮件：Trevor。burbridge@bt.com
Philip Eardley BT B54 Room 77, Adastral Park, Martlesham Ipswich, IP5 3RE UK EMail: philip.eardley@bt.com
Philip Eardley BT B54，地址：IP5 IP5伊普斯维奇市阿达斯特拉尔公园77室，英国邮箱：Philip。eardley@bt.com
Kevin J. Ma Azuki Systems, Inc. 43 Nagog Park Acton, MA 01720 USA Phone: +1 978-844-5100 EMail: kevin.ma@azukisystems.com
Kevin J.Ma Azuki Systems，Inc.美国马萨诸塞州纳戈帕克阿克顿43号01720电话：+1 978-844-5100电子邮件：Kevin。ma@azukisystems.com
Grant Watson Alcatel-Lucent (Velocix) 3 Ely Road Milton, Cambridge CB24 6AA UK EMail: gwatson@velocix.com
Grant Watson Alcatel-Lucent（Velocix）3 Ely Road Milton，Cambridge CB24 6AA英国电子邮件：gwatson@velocix.com