Internet Engineering Task Force (IETF) J. Seedorf
Request for Comments: 8008 HFT Stuttgart - Univ. of Applied Sciences
Category: Standards Track J. Peterson
ISSN: 2070-1721 Neustar
S. Previdi
Cisco
R. van Brandenburg
TNO
K. Ma
Ericsson
December 2016
Internet Engineering Task Force (IETF) J. Seedorf
Request for Comments: 8008 HFT Stuttgart - Univ. of Applied Sciences
Category: Standards Track J. Peterson
ISSN: 2070-1721 Neustar
S. Previdi
Cisco
R. van Brandenburg
TNO
K. Ma
Ericsson
December 2016
Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics
内容交付网络互连（CDNI）请求路由：占用空间和功能语义
Abstract
摘要
This document captures the semantics of the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface, i.e., the desired meaning of "Footprint" and "Capabilities" in the CDNI context and what the "Footprint & Capabilities Advertisement interface (FCI)" offers within CDNI. The document also provides guidelines for the CDNI FCI protocol. It further defines a Base Advertisement Object, the necessary registries for capabilities and footprints, and guidelines on how these registries can be extended in the future.
本文档捕获了内容交付网络互连（CDNI）请求路由接口“封装外形和功能广告”部分的语义，即CDNI上下文中“封装外形”和“功能”的期望含义以及CDNI中“封装外形和功能广告接口（FCI）”提供的内容。该文件还提供了CDNI FCI协议的指南。它进一步定义了一个基本的广告对象、功能和封装外形的必要注册中心，以及关于这些注册中心将来如何扩展的指导方针。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc8008.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8008.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 and Scope ..........................................4
1.1. Terminology ................................................5
2. Design Decisions for Footprint and Capabilities .................6
2.1. Advertising Limited Coverage ...............................6
2.2. Capabilities and Dynamic Data ..............................7
2.3. Advertisement versus Queries ...............................8
2.4. Avoiding or Handling "Cheating" dCDNs ......................8
3. Focusing on Capabilities with Footprint Restrictions ............9
4. Footprint and Capabilities Extension ............................9
5. Capability Advertisement Object ................................11
5.1. Base Advertisement Object .................................12
5.2. Encoding ..................................................12
5.3. Delivery Protocol Capability Object .......................13
5.3.1. Delivery Protocol Capability Object Serialization ..13
5.4. Acquisition Protocol Capability Object ....................14
5.4.1. Acquisition Protocol Capability Object
Serialization ......................................14
5.5. Redirection Mode Capability Object ........................15
5.5.1. Redirection Mode Capability Object Serialization ...15
5.6. CDNI Logging Capability Object ............................16
5.6.1. CDNI Logging Capability Object Serialization .......17
5.7. CDNI Metadata Capability Object ...........................18
5.7.1. CDNI Metadata Capability Object Serialization ......19
6. IANA Considerations ............................................20
6.1. CDNI Payload Types ........................................20
6.1.1. CDNI FCI DeliveryProtocol Payload Type .............20
6.1.2. CDNI FCI AcquisitionProtocol Payload Type ..........20
6.1.3. CDNI FCI RedirectionMode Payload Type ..............20
6.1.4. CDNI FCI Logging Payload Type ......................21
6.1.5. CDNI FCI Metadata Payload Type .....................21
6.2. "CDNI Capabilities Redirection Modes" Registry ............21
7. Security Considerations ........................................22
8. References .....................................................23
8.1. Normative References ......................................23
8.2. Informative References ....................................24
Appendix A. Main Use Case to Consider .............................25
Appendix B. Semantics for Footprint Advertisement .................25
Appendix C. Semantics for Capabilities Advertisement ..............27
Acknowledgments ...................................................30
Authors' Addresses ................................................30
1. Introduction and Scope ..........................................4
1.1. Terminology ................................................5
2. Design Decisions for Footprint and Capabilities .................6
2.1. Advertising Limited Coverage ...............................6
2.2. Capabilities and Dynamic Data ..............................7
2.3. Advertisement versus Queries ...............................8
2.4. Avoiding or Handling "Cheating" dCDNs ......................8
3. Focusing on Capabilities with Footprint Restrictions ............9
4. Footprint and Capabilities Extension ............................9
5. Capability Advertisement Object ................................11
5.1. Base Advertisement Object .................................12
5.2. Encoding ..................................................12
5.3. Delivery Protocol Capability Object .......................13
5.3.1. Delivery Protocol Capability Object Serialization ..13
5.4. Acquisition Protocol Capability Object ....................14
5.4.1. Acquisition Protocol Capability Object
Serialization ......................................14
5.5. Redirection Mode Capability Object ........................15
5.5.1. Redirection Mode Capability Object Serialization ...15
5.6. CDNI Logging Capability Object ............................16
5.6.1. CDNI Logging Capability Object Serialization .......17
5.7. CDNI Metadata Capability Object ...........................18
5.7.1. CDNI Metadata Capability Object Serialization ......19
6. IANA Considerations ............................................20
6.1. CDNI Payload Types ........................................20
6.1.1. CDNI FCI DeliveryProtocol Payload Type .............20
6.1.2. CDNI FCI AcquisitionProtocol Payload Type ..........20
6.1.3. CDNI FCI RedirectionMode Payload Type ..............20
6.1.4. CDNI FCI Logging Payload Type ......................21
6.1.5. CDNI FCI Metadata Payload Type .....................21
6.2. "CDNI Capabilities Redirection Modes" Registry ............21
7. Security Considerations ........................................22
8. References .....................................................23
8.1. Normative References ......................................23
8.2. Informative References ....................................24
Appendix A. Main Use Case to Consider .............................25
Appendix B. Semantics for Footprint Advertisement .................25
Appendix C. Semantics for Capabilities Advertisement ..............27
Acknowledgments ...................................................30
Authors' Addresses ................................................30
The CDNI working group is working on a set of protocols to enable the interconnection of multiple CDNs. These CDNI protocols can serve multiple purposes, as discussed in [RFC6770] -- for instance, to extend the reach of a given CDN to areas in the network that are not covered by that particular CDN.
CDNI工作组正在制定一套协议，以实现多个CDN的互连。这些CDNI协议可用于多种用途，如[RFC6770]中所述——例如，将给定CDN的覆盖范围扩展到网络中该特定CDN未覆盖的区域。
The goal of this document is to achieve a clear understanding about the semantics associated with the CDNI Request Routing Footprint & Capabilities Advertisement interface (from now on referred to as the FCI) [RFC7336], in particular the type of information a downstream CDN (dCDN) "advertises" regarding its footprint and capabilities. To narrow down undecided aspects of these semantics, this document tries to establish a common understanding of what the FCI needs to offer and accomplish in the context of CDNI.
本文档的目标是对与CDNI请求路由足迹和能力公告接口（从现在起称为FCI）[RFC7336]相关的语义有一个清晰的理解，特别是下游CDN（dCDN）“公告”的关于其足迹和能力的信息类型。为了缩小这些语义的未确定方面，本文试图对FCI在CDNI上下文中需要提供和完成的内容建立共识。
Deciding on specific protocols to use for the FCI is explicitly outside the scope of this document. However, we provide guidelines for such FCI protocols.
明确决定FCI使用的特定协议不在本文件范围内。然而，我们为此类FCI协议提供了指南。
We make the following general assumptions in this document:
我们在本文件中作出以下一般假设：
o The CDNs participating in the CDN interconnection have already performed a bootstrap process, i.e., they have connected to each other, either directly or indirectly, and can exchange information amongst each other.
o 参与CDN互连的CDN已经执行了引导过程，即它们已经直接或间接地相互连接，并且可以相互交换信息。
o The upstream CDN (uCDN) receives footprint advertisements and/or capability advertisements from a set of dCDNs. Footprint advertisements and capability advertisements need not use the same underlying protocol.
o 上游CDN（uCDN）从一组dcdn接收封装外形广告和/或能力广告。封装外形公告和功能公告不需要使用相同的底层协议。
o The uCDN receives the initial Request Routing message from the endpoint requesting the resource.
o uCDN从请求资源的端点接收初始请求路由消息。
The CDNI problem statement [RFC6707] describes the Request Routing interface as "[enabling] 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." In addition, [RFC6707] says "the CDNI Request Routing interface is also expected 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." It thus considers "resources" and "load" as capabilities to be advertised by the dCDN.
CDNI问题陈述[RFC6707]将请求路由接口描述为“[启用]上游CDN中的请求路由功能，以查询下游CDN中的请求路由功能，以确定下游CDN是否能够（并愿意）接受委托内容请求。”此外，[RFC6707]表示“CDNI请求路由接口还应使下游CDN能够向上游CDN提供（静态或动态）信息（例如，资源、占地面积、负载），以便于上游CDN请求路由系统在处理来自用户代理的后续内容请求时选择下游CDN。”因此，它考虑”“资源”和“加载”作为dCDN公布的功能。
The range of different footprint definitions and possible capabilities is very broad. Attempting to define a comprehensive advertisement solution quickly becomes intractable. The CDNI requirements document [RFC7337] lists the specific requirements for the CDNI FCI in order to disambiguate footprints and capabilities with respect to CDNI. This document defines a common understanding of what the terms "footprint" and "capabilities" mean in the context of CDNI and details the semantics of the footprint advertisement mechanism and the capability advertisement mechanism.
不同的封装外形定义和可能的功能范围非常广泛。试图定义一个全面的广告解决方案很快就会变得棘手。CDNI要求文件[RFC7337]列出了CDNI FCI的具体要求，以消除与CDNI相关的占地面积和能力的歧义。本文档定义了对CDNI上下文中术语“足迹”和“能力”含义的共同理解，并详细说明了足迹广告机制和能力广告机制的语义。
This document reuses the terminology defined in [RFC6707].
本文件重复使用了[RFC6707]中定义的术语。
Additionally, the following terms are used throughout this document and are defined as follows:
此外，本文件中使用了以下术语，其定义如下：
o Footprint: a description of a CDN's coverage area, i.e., the area from which client requests may originate for content and to which the CDN is willing to deliver content. Note: There are many ways to describe a footprint -- for example, by address range (e.g., IPv4 CIDR or IPv6 CIDR (Classless Inter-Domain Routing), network ID (e.g., Autonomous System Number (ASN)), nation boundaries (e.g., country code), or GPS coordinates. This document does not define or endorse the quality or suitability of any particular footprint description method; rather, it only defines a method for transporting known footprint descriptions in Footprint and Capabilities Advertisement messages.
o Footprint：对CDN覆盖区域的描述，即客户请求可能来自的区域，以及CDN愿意向其交付内容的区域。注意：有许多方法可以描述一个封装外形——例如，通过地址范围（例如，IPv4 CIDR或IPv6 CIDR（无类域间路由）、网络ID（例如，自治系统号（ASN））、国家边界（例如，国家代码），或GPS坐标。本文档未定义或认可任何特定示意图描述方法的质量或适用性；相反，它仅定义了在示意图和功能广告消息中传输已知示意图描述的方法。
o Capability: a feature of a dCDN upon whose support a uCDN relies when making delegation decisions. Support for a given feature can change over time and can be restricted to a limited portion of a dCDN's footprint. Note: There are many possible dCDN features that could be of interest to a uCDN. This document does not presume to define them all; rather, it describes a scheme for defining new capabilities and how to transport them in Footprint and Capabilities Advertisement messages.
o 能力：dCDN的一个特性，uCDN在作出委派决策时依赖于它的支持。对给定功能的支持可能会随着时间的推移而改变，并且可能会限制在dCDN占用空间的有限部分。注意：uCDN可能对许多可能的dCDN功能感兴趣。本文件并未假定对所有这些内容进行定义；相反，它描述了定义新功能的方案，以及如何在示意图和功能广告消息中传输这些功能。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
A large part of the difficulty in discussing the FCI lies in understanding what exactly is meant when trying to define a footprint in terms of "coverage" or "reachability". While the operators of CDNs pick strategic locations to situate Surrogates, a Surrogate with a public IPv4 address is reachable by any endpoint on the Internet, unless some policy enforcement precludes the use of the Surrogate.
讨论FCI的很大一部分困难在于理解在试图用“覆盖率”或“可达性”定义足迹时的确切含义。虽然CDN运营商选择战略位置来定位代理，但互联网上的任何端点都可以访问具有公共IPv4地址的代理，除非某些政策强制禁止使用代理。
Some CDNs aspire to cover the entire world; we refer to these as global CDNs. The footprint advertised by such a CDN in the CDNI environment would, from a coverage or reachability perspective, presumably cover all prefixes. Potentially more interesting for CDNI use cases, however, are CDNs that claim a more limited coverage area but seek to interconnect with other CDNs in order to create a single CDN fabric that shares resources.
一些CDN渴望覆盖整个世界；我们称之为全球CDN。从覆盖率或可达性的角度来看，这样一个CDN在CDNI环境中宣传的足迹可能会覆盖所有前缀。然而，对于CDNI用例来说，可能更有趣的是，CDN声称覆盖范围更有限，但寻求与其他CDN互连以创建共享资源的单个CDN结构。
Furthermore, not all capabilities need to be footprint-restricted. Depending upon the use case, the optimal semantics of "footprints with capability attributes" vs. "capabilities with footprint restrictions" are not clear.
此外，并非所有的功能都需要受到占地面积的限制。根据用例，“具有功能属性的封装外形”与“具有封装外形限制的功能”的最佳语义并不清楚。
The key to understanding the semantics of footprint advertisements and capability advertisements lies in understanding why a dCDN would advertise a limited coverage area and how a uCDN would use such advertisements to decide among one of several dCDNs. The following section will discuss some of the trade-offs and design decisions that need to be made for the CDNI FCI.
理解封装外形广告和功能广告语义的关键在于理解dCDN为什么会广告有限的覆盖区域，以及uCDN如何使用此类广告在多个dCDN中的一个进行决策。以下部分将讨论CDNI FCI需要做出的一些权衡和设计决策。
The basic use case that would motivate a dCDN to advertise limited coverage is that the CDN was built to cover only a particular portion of the Internet. For example, an ISP could purpose-build a CDN to serve only their own customers by situating Surrogates in close topological proximity to high concentrations of their subscribers. The ISP knows the prefixes it has allocated to end users and thus can easily construct a list of prefixes that its Surrogates were positioned to serve.
促使dCDN宣传有限覆盖范围的基本用例是，CDN的构建仅覆盖互联网的特定部分。例如，ISP可以专门构建一个CDN，只为其自己的客户服务，方法是将代理服务器放置在靠近其高集中度用户的位置。ISP知道它分配给最终用户的前缀，因此可以很容易地构建一个前缀列表，它的代理被定位为提供服务。
When such a purpose-built CDN interconnects with other CDNs and advertises its footprint to a uCDN, however, the original intended coverage of the CDN might not represent its actual value to the interconnection of CDNs. Consider an ISP-A and ISP-B that both field their own CDNs, which they interconnect via CDNI. A given user E, who is a customer of ISP-B, might happen to be topologically closer to a Surrogate fielded by ISP-A, if E happens to live in a region where ISP-B has few customers and ISP-A has many. In this case, is
然而，当这种专门构建的CDN与其他CDN互连并向uCDN公布其覆盖范围时，CDN的原始预期覆盖范围可能并不代表其对CDN互连的实际价值。考虑一个ISP A和ISP B，这两个字段都是它们自己的CDNs，它们通过CDNI互连。如果某个给定的用户E恰好居住在ISP-B客户很少而ISP-A客户很多的地区，那么该用户E作为ISP-B的客户，在拓扑上可能更接近ISP-A部署的代理。在这种情况下，是
it ISP-A's CDN that "covers" E? If ISP-B's CDN has a failure condition, is it up to the uCDN to understand that ISP-A's Surrogates are potentially available as backups, and if so, how does ISP-A advertise itself as a "standby" for E? What about the case where CDNs advertising to the same uCDN express overlapping coverage (for example, mixing global and limited CDNs)?
是ISP-A的CDN“覆盖”了E？如果ISP-B的CDN出现故障情况，是否由uCDN了解ISP-a的替代项可能作为备份提供，如果是，ISP-a如何将自己宣传为E的“备用”？如果向同一uCDN发布的CDN广告表示覆盖范围重叠（例如，混合使用全局CDN和有限CDN），情况如何？
The answers to these questions greatly depend on how much information the uCDN wants to use to select a dCDN. If a uCDN has three dCDNs to choose from that "cover" the IP address of user E, obviously the uCDN might be interested in knowing how optimal the coverage is from each of the dCDNs. Coverage need not be binary (i.e., either provided or not provided); dCDNs could advertise a coverage "score", for example, and provided that they all reported scores fairly on the same scale, uCDNs could use that information to make their topological optimality decision. Alternately, dCDNs could advertise the IP addresses of their Surrogates rather than prefix "coverage" and let the uCDN decide for itself (based on its own topological intelligence) which dCDN has better resources to serve a given user.
这些问题的答案在很大程度上取决于uCDN想要使用多少信息来选择dCDN。如果一个uCDN有三个DCDN可从该“覆盖”用户E的IP地址中选择，那么显然，uCDN可能有兴趣知道每个DCDN的覆盖率有多高。覆盖范围不需要是二进制的（即，提供或不提供）；例如，dCDNs可以公布覆盖率“分数”，如果他们都在相同的尺度上公平地报告分数，uCDNs可以使用该信息做出拓扑优化决策。或者，dCDNs可以公布其代理的IP地址，而不是前缀“coverage”，并让uCDN自行决定（基于其自身的拓扑智能）哪个dCDN具有更好的资源来为给定用户服务。
In summary, the semantics of advertising a footprint depend on whether (1) such qualitative metrics for expressing a footprint (such as the coverage "score" mentioned above) are included as part of the CDNI FCI or (2) the focus is just on a "binary" footprint.
总之，足迹广告的语义取决于（1）表达足迹的定性指标（如上文提到的覆盖率“分数”）是否作为CDNI FCI的一部分包含，或者（2）关注点仅仅是“二元”足迹。
In cases where the apparent footprints of dCDNs overlap, uCDNs might also want to rely on other factors to evaluate the respective merits of dCDNs. These include facts related to the Surrogates themselves, the network where the Surrogate is deployed, the nature of the resource sought, and the administrative policies of the respective networks.
在DCDN的明显足迹重叠的情况下，UCDN可能还希望依赖其他因素来评估DCDN的各自优点。这些包括与代理本身、代理部署的网络、所寻求资源的性质以及各自网络的管理策略有关的事实。
In the absence of network-layer impediments to reaching Surrogates, the choice to limit coverage is, by necessity, an administrative policy. Much policy needs to be agreed upon before CDNs can interconnect, including questions of membership, compensation, volumes, and so on. A uCDN certainly will factor these sorts of considerations into its decision to select a dCDN, but there is probably little need for dCDNs to actually advertise them through an interface -- they will be settled out-of-band as a precondition for interconnection.
在没有网络层障碍的情况下，限制覆盖范围的选择必然是一项行政政策。CDN实现互联之前，需要商定许多政策，包括成员资格、薪酬、数量等问题。uCDN当然会在选择dCDN的决定中考虑这些因素，但dCDN可能几乎不需要通过接口实际公布它们——它们将在带外解决，作为互连的先决条件。
Other facts about the dCDN would be expressed through the interface to the uCDN. Some capabilities of a dCDN are static, and some are highly dynamic. Expressing the total storage built into its Surrogates, for example, changes relatively rarely, whereas the
关于dCDN的其他事实将通过uCDN接口表达。dCDN的某些功能是静态的，而有些功能是高度动态的。例如，表示内置到其代理中的总存储相对很少更改，而
amount of storage in use at any given moment is highly volatile. Network bandwidth similarly could be expressed either as total bandwidth available to a Surrogate or based on the current state of the network. A Surrogate can at one moment lack a particular resource in storage but have it the next.
在任何给定时刻使用的存储量都是高度不稳定的。网络带宽类似地可以表示为代理可用的总带宽或基于网络的当前状态。代理可以在某一时刻缺少存储中的特定资源，但在下一时刻却拥有它。
The semantics of the capabilities interface will depend on how much of the dCDN state needs to be pushed to the uCDN and, qualitatively, how often that information needs to be updated.
capabilities接口的语义将取决于需要将多少dCDN状态推送到uCDN，以及定性地取决于需要更新该信息的频率。
In a CDNI environment, each dCDN shares some of its state with the uCDN. The uCDN uses this information to build a unified picture of all of the dCDNs available to it. In architectures that share detailed capability information, the uCDN could perform the entire Request Routing operation down to selecting a particular Surrogate in the dCDN. However, when the uCDN needs to deal with many potential dCDNs, this approach does not scale, especially for dCDNs with thousands or tens of thousands of Surrogates; the volume of updates to the footprint and the capability information becomes onerous.
在CDNI环境中，每个dCDN都与uCDN共享其一些状态。uCDN使用此信息构建其可用的所有DCDN的统一图片。在共享详细功能信息的体系结构中，uCDN可以执行整个请求路由操作，直到在dCDN中选择特定的代理。然而，当uCDN需要处理许多潜在的DCDN时，这种方法无法扩展，特别是对于具有数千或上万个代理的DCDN；足迹和能力信息的更新量变得非常繁重。
Were the volume of FCI updates from dCDNs to exceed the volume of requests to the uCDN, it might make more sense for the uCDN to query dCDNs upon receiving requests (as is the case in the recursive redirection mode described in [RFC7336]), instead of receiving advertisements and tracking the state of dCDNs. The advantage of querying dCDNs would be that much of the dynamic data that dCDNs cannot share with the uCDN would now be factored into the uCDN's decision. dCDNs need not replicate any state to the uCDN -- uCDNs could effectively operate in a stateless mode.
如果来自dCDNs的FCI更新量超过对uCDN的请求量，uCDN在收到请求时查询dCDNs（如[RFC7336]中所述的递归重定向模式中的情况）可能更有意义，而不是接收播发和跟踪DCDN的状态。查询dCDNs的优点是，dCDNs无法与uCDN共享的许多动态数据现在将被考虑到uCDN的决策中。dCDNs不需要将任何状态复制到uCDN——uCDNs可以有效地在无状态模式下运行。
The semantics of both footprint advertisements and capability advertisements depend on the service model here: are there cases where a synchronous query/response model would work better for the uCDN decision than a state replication model?
封装外形广告和功能广告的语义都取决于此处的服务模型：是否存在同步查询/响应模型比状态复制模型更适合uCDN决策的情况？
In a situation where more than one dCDN is willing to serve a given end user request, it might be attractive for a dCDN to "cheat" in the sense that the dCDN provides inaccurate information to the uCDN in order to convince the uCDN to select it over "competing" dCDNs. It could therefore be desirable to take away the incentive for dCDNs to cheat (in information advertised) as much as possible. One option is to make the information the dCDN advertises somehow verifiable for the uCDN. On the other hand, a "cheating" dCDN might be avoided or
在多个dCDN愿意为给定的最终用户请求提供服务的情况下，dCDN“欺骗”可能是有吸引力的，因为dCDN向uCDN提供不准确的信息，以便说服uCDN选择它而不是“竞争”dCDN。因此，最好尽可能消除dCDNs欺骗（广告信息）的动机。一种选择是使dCDN播发的信息能够以某种方式验证uCDN。另一方面，可以避免或避免“欺骗”dCDN
handled by the fact that there will be strong contractual agreements between a uCDN and a dCDN, so that a dCDN would risk severe penalties or legal consequences when caught cheating.
由于uCDN和dCDN之间存在强有力的合同协议，因此dCDN在被发现作弊时将面临严厉的惩罚或法律后果。
Overall, the information a dCDN advertises (in the long run) needs to be somehow qualitatively verifiable by the uCDN, though possibly through non-real-time out-of-band audits. It is probably an overly strict requirement to mandate that such verification be possible "immediately", i.e., during the Request Routing process itself. If the uCDN can detect a cheating dCDN at a later stage, it might suffice for the uCDN to "de-incentivize" cheating because it would negatively affect the long-term business relationship with a particular dCDN.
总的来说，dCDN发布的信息（从长远来看）需要uCDN以某种方式进行定性验证，尽管可能通过非实时带外审核。这可能是一个过于严格的要求，要求“立即”进行此类验证，即在请求路由过程本身期间。如果uCDN能够在以后的阶段检测到作弊dCDN，uCDN就可以“去激励”作弊，因为这会对与特定dCDN的长期业务关系产生负面影响。
Given the design considerations listed in the previous section, it seems reasonable to assume that in most cases it is the uCDN that makes the decision to select a certain dCDN for Request Routing based on information the uCDN has received from this particular dCDN. It can be assumed that cheating dCDNs will be dealt with via means outside the scope of CDNI and that the information advertised between CDNs is accurate. In addition, excluding the use of qualitative information (e.g., Surrogate proximity, delivery latency, Surrogate load) to predict the quality of delivery would further simplify the use case, allowing it to better focus on the basic functionality of the FCI.
鉴于上一节中列出的设计考虑因素，似乎可以合理地假设，在大多数情况下，是uCDN根据uCDN从该特定dCDN收到的信息决定选择某个dCDN进行请求路由。可以假设，作弊的DCDN将通过CDNI范围之外的方式处理，并且CDN之间公布的信息是准确的。此外，排除使用定性信息（例如，代理接近度、交付延迟、代理负载）来预测交付质量将进一步简化用例，使其能够更好地关注FCI的基本功能。
Furthermore, understanding that in most cases contractual agreements will define the basic coverage used in delegation decisions, the primary focus of the FCI is on providing updates to the basic capabilities and coverage by the dCDNs. As such, the FCI has chosen the semantics of "capabilities with footprint restrictions".
此外，了解到在大多数情况下，合同协议将定义委托决策中使用的基本覆盖范围，FCI的主要重点是更新dCDNs的基本能力和覆盖范围。因此，FCI选择了“具有足迹限制的功能”的语义。
Other optional "coverage/reachability" footprint types or "resource" footprint types may be defined by future specifications. To facilitate this, a clear process for specifying optional footprint types in an IANA registry is specified in the "CDNI Metadata Footprint Types" registry (defined in the CDNI Metadata interface document [RFC8006]).
其他可选的“覆盖/可达性”封装外形类型或“资源”封装外形类型可由未来的规范定义。为了促进这一点，在“CDNI元数据封装外形类型”注册表（在CDNI元数据接口文档[RFC8006]中定义）中指定了在IANA注册表中指定可选封装外形类型的清晰过程。
This document also registers CDNI Payload Types [RFC7736] for the initial capability types (see Section 6):
本文件还登记了初始能力类型的CDNI有效载荷类型[RFC7736]（见第6节）：
o Delivery Protocol (for delivering content to the end user)
o 交付协议（用于向最终用户交付内容）
o Acquisition Protocol (for acquiring content from the uCDN or origin server)
o 获取协议（用于从uCDN或源服务器获取内容）
o Redirection Mode (e.g., DNS redirection vs. HTTP redirection as discussed in [RFC7336])
o 重定向模式（如[RFC7336]中讨论的DNS重定向与HTTP重定向）
o CDNI Logging (i.e., supported CDNI Logging fields)
o CDNI日志记录（即支持的CDNI日志记录字段）
o CDNI Metadata (i.e., supported GenericMetadata types)
o CDNI元数据（即受支持的GenericMetadata类型）
Each Payload Type is prefaced with "FCI.". Updates to capability objects MUST indicate the version of the capability object in a newly registered Payload Type, e.g., by appending ".v2". Each capability type MAY have a list of valid values. Future specifications that define a given capability MUST define any necessary registries (and the rules for adding new entries to the registry) for the values advertised for a given capability type.
每种有效负载类型都以“FCI”开头。对能力对象的更新必须以新注册的有效负载类型指示能力对象的版本，例如，通过添加“.v2”。每个功能类型都可能有一个有效值列表。定义给定功能的未来规范必须为给定功能类型的播发值定义任何必要的注册表（以及向注册表添加新条目的规则）。
The "CDNI Logging record-types" registry [RFC7937] defines all known record-types, including "mandatory-to-implement" record-types. Advertising support for mandatory-to-implement record-types would be redundant. CDNs SHOULD NOT advertise support for mandatory-to-implement record-types.
“CDNI日志记录类型”注册表[RFC7937]定义了所有已知的记录类型，包括“强制实现”记录类型。对强制实现记录类型的广告支持是多余的。CDN不应公布对强制实现记录类型的支持。
The "CDNI Logging Field Names" registry [RFC7937] defines all known CDNI Logging fields. CDNI Logging fields may be reused by different record-types and be mandatory-to-implement in some record-types, but they may be optional in other record-types. CDNs MUST advertise support for optional CDNI Logging fields within the context of a specific record-type. For a given record-type, CDNs SHOULD NOT advertise support for mandatory-to-implement CDNI Logging fields. The following CDNI Logging fields are defined as optional for the "cdni_http_request_v1" record-type [RFC7937]:
“CDNI日志记录字段名称”注册表[RFC7937]定义了所有已知的CDNI日志记录字段。CDNI日志记录字段可以被不同的记录类型重用，并且在某些记录类型中必须实现，但在其他记录类型中可能是可选的。CDN必须在特定记录类型的上下文中公布对可选CDNI日志字段的支持。对于给定的记录类型，CDN不应公布对强制实现CDNI日志字段的支持。以下CDNI日志字段被定义为“CDNI_http_请求_v1”记录类型[RFC7937]的可选字段：
o s-ccid
o s-ccid
o s-sid
o s-sid
[RFC8006] requires that CDNs be able to parse all the defined metadata objects but does not require dCDNs to support enforcement of non-structural GenericMetadata objects. Advertising support for "mandatory-to-enforce" GenericMetadata types MUST be provided. Advertising support for non-mandatory-to-enforce GenericMetadata
[RFC8006]要求CDN能够解析所有定义的元数据对象，但不要求dCDNs支持非结构化GenericMetadata对象的实施。必须提供对“强制执行”GenericMetadata类型的广告支持。广告支持非强制执行GenericMetadata
types SHOULD be provided. Advertisement of non-mandatory-to-enforce GenericMetadata MAY be necessary, e.g., to signal temporary outages and subsequent recovery. It is expected that structural metadata will be supported at all times.
应提供类型。可能需要发布非强制性的公告来强制执行GenericMetadata，例如，发出临时停机和后续恢复的信号。预计将始终支持结构元数据。
The notion of optional footprint types and capability types implies that certain implementations might not support all kinds of footprints and capabilities. Therefore, any FCI solution protocol MUST define how the support for optional footprint types and capability types will be negotiated between a uCDN and a dCDN that use the particular FCI protocol. In particular, any FCI solution protocol MUST specify how to handle failure cases or non-supported footprint or capability types.
可选封装外形类型和功能类型的概念意味着某些实现可能不支持所有类型的封装外形和功能。因此，任何FCI解决方案协议都必须定义如何在使用特定FCI协议的uCDN和dCDN之间协商对可选封装外形类型和功能类型的支持。特别是，任何FCI解决方案协议都必须指定如何处理故障情况或不受支持的封装外形或功能类型。
In general, a uCDN MAY ignore capabilities or footprint types it does not understand; in this case, it only selects a suitable dCDN based on the types of capabilities and footprints it understands. Similarly, if a dCDN does not use an optional capability or footprint that is, however, supported by a uCDN, this causes no problem for FCI functionality because the uCDN decides on the remaining capabilities/footprint information that is being conveyed by the dCDN.
通常，uCDN可能会忽略它不了解的功能或封装外形类型；在这种情况下，它仅根据其了解的功能类型和封装外形选择合适的dCDN。类似地，如果dCDN不使用uCDN支持的可选功能或封装外形，这不会导致FCI功能出现问题，因为uCDN决定dCDN传递的剩余功能/封装外形信息。
To support extensibility, the FCI defines a generic base object (similar to the CDNI Metadata interface GenericMetadata object) [RFC8006] to facilitate a uniform set of mandatory parsing requirements for all future FCI objects.
为了支持可扩展性，FCI定义了一个通用的基本对象（类似于CDNI元数据接口GenericMetadata对象）[RFC8006]，以便为所有未来FCI对象提供统一的强制解析要求。
Future object definitions (e.g., regarding the CDNI Metadata or CDNI Logging interfaces) will build off the base object defined here but will be specified in separate documents.
未来的对象定义（例如，关于CDNI元数据或CDNI日志接口）将基于此处定义的基本对象构建，但将在单独的文档中指定。
Note: In the following sections, the term "mandatory-to-specify" is used to convey which properties MUST be included when serializing a given capability object. When mandatory-to-specify is defined as "Yes" for an individual property, it means that if the object containing that property is included in an FCI message, then the mandatory-to-specify property MUST also be included.
注意：在以下部分中，术语“必须指定”用于表示序列化给定功能对象时必须包括哪些属性。当单个属性的“必须指定”定义为“是”时，这意味着如果包含该属性的对象包含在FCI消息中，则还必须包含“必须指定”属性。
The FCIBase object is an abstraction for managing individual CDNI capabilities in an opaque manner.
FCIBase对象是以不透明方式管理单个CDNI功能的抽象。
Property: capability-type
属性：功能类型
Description: CDNI capability object type.
描述：CDNI能力对象类型。
Type: FCI-specific CDNI Payload Type (from the "CDNI Payload Types" registry [RFC7736])
类型：FCI特定的CDNI有效负载类型（来自“CDNI有效负载类型”注册表[RFC7736]）
Mandatory-to-Specify: Yes.
必须指定：是。
Property: capability-value
属性：能力值
Description: CDNI capability object.
描述：CDNI能力对象。
Type: Format/Type is defined by the value of the capability-type property above
类型：格式/类型由上述功能类型属性的值定义
Mandatory-to-Specify: Yes.
必须指定：是。
Property: footprints
属性：脚印
Description: CDNI capability footprint.
描述：CDNI能力足迹。
Type: List of CDNI Footprint objects (from the "CDNI Metadata Footprint Types" registry [RFC8006])
类型：CDNI封装外形对象列表（来自“CDNI元数据封装外形类型”注册表[RFC8006]）
Mandatory-to-Specify: No.
必须指定：否。
CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also follow the recommendations of I-JSON (Internet JSON) [RFC7493]. FCI objects are composed of a dictionary of (key,value) pairs where the keys are the property names and the values are the associated property values.
CDNI FCI对象必须使用JSON[RFC7159]进行编码，并且还必须遵循I-JSON（互联网JSON）[RFC7493]的建议。FCI对象由（键、值）对字典组成，其中键是属性名称，值是关联的属性值。
The keys of the dictionary are the names of the properties associated with the object and are therefore dependent on the specific object being encoded (i.e., dependent on the CDNI Payload Type of the capability or the CDNI Metadata Footprint Type of the footprint). Likewise, the values associated with each property (dictionary key) are dependent on the specific object being encoded (i.e., dependent on the CDNI Payload Type of the capability or the CDNI Metadata Footprint Type of the footprint).
字典的键是与对象关联的属性的名称，因此取决于正在编码的特定对象（即，取决于能力的CDNI有效负载类型或封装外形的CDNI元数据封装外形类型）。同样，与每个属性（字典键）关联的值取决于正在编码的特定对象（即，取决于能力的CDNI有效负载类型或封装外形的CDNI元数据封装外形类型）。
Dictionary keys (properties) in JSON are case sensitive. By convention, any dictionary key (property) defined by this document MUST be lowercase.
JSON中的字典键（属性）区分大小写。按照惯例，本文档定义的任何字典键（属性）必须是小写的。
The Delivery Protocol capability object is used to indicate support for one or more of the protocols listed in the "CDNI Metadata Protocol Types" registry (defined in [RFC8006]).
Delivery Protocol capability对象用于表示对“CDNI元数据协议类型”注册表（在[RFC8006]中定义）中列出的一个或多个协议的支持。
Property: delivery-protocols
属性：传递协议
Description: List of supported CDNI delivery protocols.
描述：支持的CDNI交付协议列表。
Type: List of protocol types (from the "CDNI Metadata Protocol Types" registry [RFC8006])
类型：协议类型列表（来自“CDNI元数据协议类型”注册表[RFC8006]）
Mandatory-to-Specify: Yes.
必须指定：是。
The following shows an example of Delivery Protocol capability object serialization for a CDN that supports only HTTP/1.1 without Transport Layer Security (TLS) for content delivery.
下面显示了CDN的传递协议功能对象序列化示例，该CDN仅支持HTTP/1.1，而不支持用于内容传递的传输层安全性（TLS）。
{
"capabilities": [
{
"capability-type": "FCI.DeliveryProtocol",
"capability-value": {
"delivery-protocols": [
"http/1.1",
]
},
"footprints": [
<Footprint objects>
]
}
]
}
{
"capabilities": [
{
"capability-type": "FCI.DeliveryProtocol",
"capability-value": {
"delivery-protocols": [
"http/1.1",
]
},
"footprints": [
<Footprint objects>
]
}
]
}
The Acquisition Protocol capability object is used to indicate support for one or more of the protocols listed in the "CDNI Metadata Protocol Types" registry (defined in [RFC8006]).
Acquisition Protocol capability对象用于表示对“CDNI元数据协议类型”注册表（在[RFC8006]中定义）中列出的一个或多个协议的支持。
Property: acquisition-protocols
属性：采集协议
Description: List of supported CDNI acquisition protocols.
描述：支持的CDNI采集协议列表。
Type: List of protocol types (from the "CDNI Metadata Protocol Types" registry [RFC8006])
类型：协议类型列表（来自“CDNI元数据协议类型”注册表[RFC8006]）
Mandatory-to-Specify: Yes.
必须指定：是。
The following shows an example of Acquisition Protocol capability object serialization for a CDN that supports HTTP/1.1 with or without TLS for content acquisition.
以下显示了支持HTTP/1.1（带或不带TLS）的CDN的采集协议功能对象序列化示例，用于内容采集。
{
"capabilities": [
{
"capability-type": "FCI.AcquisitionProtocol",
"capability-value": {
"acquisition-protocols": [
"http/1.1",
"https/1.1"
]
},
"footprints": [
<Footprint objects>
]
}
]
}
{
"capabilities": [
{
"capability-type": "FCI.AcquisitionProtocol",
"capability-value": {
"acquisition-protocols": [
"http/1.1",
"https/1.1"
]
},
"footprints": [
<Footprint objects>
]
}
]
}
The Redirection Mode capability object is used to indicate support for one or more of the modes listed in the "CDNI Capabilities Redirection Modes" registry (see Section 6.2).
重定向模式功能对象用于指示对“CDNI功能重定向模式”注册表中列出的一种或多种模式的支持（参见第6.2节）。
Property: redirection-modes
属性：重定向模式
Description: List of supported CDNI redirection modes.
描述：支持的CDNI重定向模式列表。
Type: List of redirection modes (from the "CDNI Capabilities Redirection Modes" registry, defined in Section 6.2)
类型：重定向模式列表（来自第6.2节中定义的“CDNI功能重定向模式”注册表）
Mandatory-to-Specify: Yes.
必须指定：是。
The following shows an example of Redirection Mode capability object serialization for a CDN that supports only iterative (i.e., not recursive) redirection with HTTP and DNS.
以下显示了CDN的重定向模式功能对象序列化示例，该CDN仅支持使用HTTP和DNS的迭代（即，非递归）重定向。
{
"capabilities": [
{
"capability-type": "FCI.RedirectionMode",
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
"footprints": [
<Footprint objects>
]
}
]
}
{
"capabilities": [
{
"capability-type": "FCI.RedirectionMode",
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
"footprints": [
<Footprint objects>
]
}
]
}
The CDNI Logging capability object is used to indicate support for CDNI Logging record-types, as well as CDNI Logging fields that are marked as optional for the specified record-types [RFC7937].
CDNI日志记录功能对象用于指示对CDNI日志记录类型的支持，以及对指定记录类型标记为可选的CDNI日志记录字段的支持[RFC7937]。
Property: record-type
属性：记录类型
Description: Supported CDNI Logging record-type.
描述：支持的CDNI日志记录类型。
Type: String corresponding to an entry from the "CDNI Logging record-types" registry [RFC7937]
类型：对应于“CDNI日志记录类型”注册表项的字符串[RFC7937]
Mandatory-to-Specify: Yes.
必须指定：是。
Property: fields
属性：字段
Description: List of supported CDNI Logging fields that are optional for the specified record-type.
描述：支持的CDNI日志记录字段列表，这些字段对于指定的记录类型是可选的。
Type: List of strings corresponding to entries from the "CDNI Logging Field Names" registry [RFC7937]
类型：与“CDNI日志记录字段名称”注册表项对应的字符串列表[RFC7937]
Mandatory-to-Specify: No. Default is that all optional fields are supported. Omission of this field MUST be interpreted as "all optional fields are supported". An empty list MUST be interpreted as "no optional fields are supported". Otherwise, if a list of fields is provided, the fields in that list MUST be interpreted as "the only optional fields that are supported".
必须指定：否。默认情况下，支持所有可选字段。省略此字段必须解释为“支持所有可选字段”。空列表必须解释为“不支持可选字段”。否则，如果提供了字段列表，则该列表中的字段必须解释为“支持的唯一可选字段”。
The following shows an example of CDNI Logging capability object serialization for a CDN that supports the optional Content Collection ID CDNI Logging field (but not the optional Session ID CDNI Logging field) for the "cdni_http_request_v1" record-type.
下面显示了CDN的CDNI日志功能对象序列化示例，该CDN支持“CDNI\u http\u request\u v1”记录类型的可选内容集合ID CDNI日志字段（但不支持可选会话ID CDNI日志字段）。
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": ["s-ccid"]
},
"footprints": [
<Footprint objects>
]
}
]
}
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": ["s-ccid"]
},
"footprints": [
<Footprint objects>
]
}
]
}
The next example shows the CDNI Logging capability object serialization for a CDN that supports all optional fields for the "cdni_http_request_v1" record-type.
下一个示例显示CDN的CDNI日志功能对象序列化，该CDN支持“CDNI_http_request_v1”记录类型的所有可选字段。
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1"
},
"footprints": [
<Footprint objects>
]
}
]
}
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1"
},
"footprints": [
<Footprint objects>
]
}
]
}
The final example shows the CDNI Logging capability object serialization for a CDN that supports none of the optional fields for the "cdni_http_request_v1" record-type.
最后一个示例显示了CDN的CDNI日志功能对象序列化，该CDN不支持“CDNI_http_request_v1”记录类型的任何可选字段。
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": []
},
"footprints": [
<Footprint objects>
]
}
]
}
{
"capabilities": [
{
"capability-type": "FCI.Logging",
"capability-value": {
"record-type": "cdni_http_request_v1",
"fields": []
},
"footprints": [
<Footprint objects>
]
}
]
}
The CDNI Metadata capability object is used to indicate support for CDNI GenericMetadata types [RFC8006].
CDNI元数据功能对象用于表示支持CDNI GenericMetadata类型[RFC8006]。
Property: metadata
属性：元数据
Description: List of supported CDNI GenericMetadata types.
描述：支持的CDNI GenericMetadata类型列表。
Type: List of strings corresponding to entries from the "CDNI Payload Types" registry [RFC7736] that correspond to CDNI GenericMetadata objects
类型：与“CDNI有效负载类型”注册表[RFC7736]中对应于CDNI GenericMetadata对象的条目相对应的字符串列表
Mandatory-to-Specify: Yes. An empty list MUST be interpreted as "no GenericMetadata types are supported", i.e., "only structural metadata and simple types are supported"; otherwise, the list must be interpreted as containing "the only GenericMetadata types that are supported" (in addition to structural metadata and simple types) [RFC8006].
必须指定：是。空列表必须解释为“不支持GenericMetadata类型”，即“仅支持结构元数据和简单类型”；否则，该列表必须解释为包含“仅支持的GenericMetadata类型”（除了结构元数据和简单类型之外）[RFC8006]。
The following shows an example of CDNI Metadata capability object serialization for a CDN that supports only the SourceMetadata GenericMetadata type (i.e., it can acquire and deliver content but cannot enforce any security policies, e.g., time, location, or protocol Access Control Lists (ACLs)).
以下显示了CDN的CDNI元数据功能对象序列化示例，该CDN仅支持SourceMetadata GenericMetadata类型（即，它可以获取和交付内容，但不能强制执行任何安全策略，例如时间、位置或协议访问控制列表（ACL））。
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": ["MI.SourceMetadata"]
},
"footprints": [
<Footprint objects>
]
}
]
}
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": ["MI.SourceMetadata"]
},
"footprints": [
<Footprint objects>
]
}
]
}
The next example shows the CDNI Metadata capability object serialization for a CDN that supports only structural metadata (i.e., it can parse metadata as a transit CDN but cannot enforce security policies or deliver content).
下一个示例显示了仅支持结构元数据的CDN的CDNI元数据功能对象序列化（即，它可以将元数据解析为传输CDN，但不能强制执行安全策略或交付内容）。
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": []
},
"footprints": [
<Footprint objects>
]
}
]
}
{
"capabilities": [
{
"capability-type": "FCI.Metadata",
"capability-value": {
"metadata": []
},
"footprints": [
<Footprint objects>
]
}
]
}
This document registers the following CDNI Payload Types under the IANA "CDNI Payload Types" registry:
本文件在IANA“CDNI有效负载类型”注册表下注册了以下CDNI有效负载类型：
+-------------------------+---------------+
| Payload Type | Specification |
+-------------------------+---------------+
| FCI.DeliveryProtocol | RFC 8008 |
| FCI.AcquisitionProtocol | RFC 8008 |
| FCI.RedirectionMode | RFC 8008 |
| FCI.Logging | RFC 8008 |
| FCI.Metadata | RFC 8008 |
+-------------------------+---------------+
+-------------------------+---------------+
| Payload Type | Specification |
+-------------------------+---------------+
| FCI.DeliveryProtocol | RFC 8008 |
| FCI.AcquisitionProtocol | RFC 8008 |
| FCI.RedirectionMode | RFC 8008 |
| FCI.Logging | RFC 8008 |
| FCI.Metadata | RFC 8008 |
+-------------------------+---------------+
Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported delivery protocols
目的：此有效负载类型的目的是区分支持的传递协议的FCI播发对象
Interface: FCI
接口：FCI
Encoding: see Section 5.3
编码：见第5.3节
Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported acquisition protocols
目的：此有效负载类型的目的是区分支持的采集协议的FCI播发对象
Interface: FCI
接口：FCI
Encoding: see Section 5.4
编码：见第5.4节
Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported redirection modes
目的：此有效负载类型的目的是区分支持重定向模式的FCI播发对象
Interface: FCI
接口：FCI
Encoding: see Section 5.5
编码：见第5.5节
Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported CDNI Logging record-types and optional CDNI Logging field names
目的：此有效负载类型的目的是区分支持的CDNI日志记录类型和可选的CDNI日志记录字段名称的FCI播发对象
Interface: FCI
接口：FCI
Encoding: see Section 5.6
编码：见第5.6节
Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported CDNI GenericMetadata types
目的：此有效负载类型的目的是区分支持的CDNI GenericMetadata类型的FCI播发对象
Interface: FCI
接口：FCI
Encoding: see Section 5.7
编码：见第5.7节
IANA has created a new "CDNI Capabilities Redirection Modes" registry in the "Content Delivery Network Interconnection (CDNI) Parameters" registry. The "CDNI Capabilities Redirection Modes" namespace defines the valid redirection modes that can be advertised as supported by a CDN. Additions to the "CDNI Capabilities Redirection Modes" namespace conform to the IETF Review policy as defined in [RFC5226].
IANA在“内容交付网络互连（CDNI）参数”注册表中创建了一个新的“CDNI功能重定向模式”注册表。“CDNI功能重定向模式”命名空间定义了CDN支持的有效重定向模式。“CDNI能力重定向模式”命名空间的新增内容符合[RFC5226]中定义的IETF审查政策。
The following table defines the initial redirection modes:
下表定义了初始重定向模式：
+------------------+----------------------------------+----------+
| Redirection Mode | Description | RFC |
+------------------+----------------------------------+----------+
| DNS-I | Iterative DNS-based Redirection | RFC 8008 |
| DNS-R | Recursive DNS-based Redirection | RFC 8008 |
| HTTP-I | Iterative HTTP-based Redirection | RFC 8008 |
| HTTP-R | Recursive HTTP-based Redirection | RFC 8008 |
+------------------+----------------------------------+----------+
+------------------+----------------------------------+----------+
| Redirection Mode | Description | RFC |
+------------------+----------------------------------+----------+
| DNS-I | Iterative DNS-based Redirection | RFC 8008 |
| DNS-R | Recursive DNS-based Redirection | RFC 8008 |
| HTTP-I | Iterative HTTP-based Redirection | RFC 8008 |
| HTTP-R | Recursive HTTP-based Redirection | RFC 8008 |
+------------------+----------------------------------+----------+
This specification describes the semantics for capabilities and footprint advertisement objects across interconnected CDNs. It does not, however, specify a concrete protocol for transporting those objects. Specific security mechanisms can only be selected for concrete protocols that instantiate these semantics. This document does, however, place some high-level security constraints on such protocols.
本规范描述了跨互连CDN的功能和封装外形广告对象的语义。但是，它没有为传输这些对象指定具体的协议。只能为实例化这些语义的具体协议选择特定的安全机制。然而，本文档确实对此类协议设置了一些高级安全约束。
All protocols that implement these capabilities and footprint advertisement objects are REQUIRED to provide integrity and authentication services. Without authentication and integrity, an attacker could trivially deny service by forging a footprint advertisement from a dCDN that claims the network has no footprint or capability. This would prevent the uCDN from delegating any requests to the dCDN. Since a preexisting relationship between all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary credentials could be conducted before the FCI is brought online. The authorization decision to accept advertisements would also follow this preexisting relationship and any contractual obligations that it stipulates.
实现这些功能和封装外形广告对象的所有协议都需要提供完整性和身份验证服务。在没有身份验证和完整性的情况下，攻击者可以通过从声称网络没有足迹或功能的dCDN伪造足迹广告来拒绝服务。这将阻止uCDN将任何请求委托给dCDN。由于CDNI假设所有DCDN和UCDN之间存在预先存在的关系，因此可以在FCI联机之前进行任何必要凭证的交换。接受广告的授权决定也将遵循这一先前存在的关系及其规定的任何合同义务。
All protocols that implement these capabilities and footprint advertisement objects are REQUIRED to provide confidentiality services. Some dCDNs are willing to share information about their footprints or capabilities with a uCDN but not with other, competing dCDNs. For example, if a dCDN incurs an outage that reduces footprint coverage temporarily, that event could be information the dCDN would want to share confidentially with the uCDN.
实现这些功能和封装外形广告对象的所有协议都需要提供保密服务。一些DCDN愿意与uCDN共享有关其封装外形或功能的信息，但不愿意与其他竞争DCDN共享。例如，如果一个dCDN发生了一次中断，导致占用范围暂时减少，则该事件可能是dCDN希望与uCDN秘密共享的信息。
As specified in this document, the security requirements of the FCI could be met by transport-layer security mechanisms coupled with domain certificates as credentials (e.g., TLS transport for HTTP as per [RFC2818] and [RFC7230], with usage guidance from [RFC7525]) between CDNs. There is no apparent need for further object-level security in this framework, as the trust relationships it defines are bilateral relationships between uCDNs and dCDNs rather than transitive relationships.
如本文件所述，可通过传输层安全机制以及域证书作为凭证（例如，根据[RFC2818]和[RFC7230]以及[RFC7525]提供的使用指南）在CDN之间满足FCI的安全要求。在这个框架中，显然不需要进一步的对象级安全性，因为它定义的信任关系是uCDNs和dCDNs之间的双边关系，而不是传递关系。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，DOI 10.17487/RFC7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7336]Peterson，L.，Davie，B.，和R.van Brandenburg，编辑，“内容分发网络互连框架（CDNI）”，RFC 7336，DOI 10.17487/RFC7336，2014年8月<http://www.rfc-editor.org/info/rfc7336>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <http://www.rfc-editor.org/info/rfc7493>.
[RFC7493]Bray，T.，Ed.，“I-JSON消息格式”，RFC 7493，DOI 10.17487/RFC7493，2015年3月<http://www.rfc-editor.org/info/rfc7493>.
[RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., and R. Peterkofsky, "Content Distribution Network Interconnection (CDNI) Logging Interface", RFC 7937, DOI 10.17487/RFC7937, August 2016, <http://www.rfc-editor.org/info/rfc7937>.
[RFC7937]Le Faucheur，F.，Ed.，Bertrand，G.，Ed.，Oprescu，I.，Ed.，和R.Peterkofsky，“内容分发网络互连（CDNI）记录接口”，RFC 7937，DOI 10.17487/RFC7937，2016年8月<http://www.rfc-editor.org/info/rfc7937>.
[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, <http://www.rfc-editor.org/info/rfc8006>.
[RFC8006]Niven Jenkins，B.，Murray，R.，Caulfield，M.，和K.Ma，“内容交付网络互连（CDNI）元数据”，RFC 8006，DOI 10.17487/RFC8006，2016年12月<http://www.rfc-editor.org/info/rfc8006>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, DOI 10.17487/RFC6707, September 2012, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6707]Niven Jenkins，B.，Le Faucheur，F.，和N.Bitar，“内容分发网络互连（CDNI）问题声明”，RFC 6707，DOI 10.17487/RFC6707，2012年9月<http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, November 2012, <http://www.rfc-editor.org/info/rfc6770>.
[RFC6770]Bertrand，G.，Ed.，Stephan，E.，Burbridge，T.，Eardley，P.，Ma，K.，和G.Watson，“内容交付网络互连的用例”，RFC 6770，DOI 10.17487/RFC6770，2012年11月<http://www.rfc-editor.org/info/rfc6770>.
[RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7337] Leung, K., Ed., and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, <http://www.rfc-editor.org/info/rfc7337>.
[RFC7337]Leung，K.，Ed.，和Y.Lee，Ed.“内容分发网络互连（CDNI）要求”，RFC 7337，DOI 10.17487/RFC7337，2014年8月<http://www.rfc-editor.org/info/rfc7337>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, <http://www.rfc-editor.org/info/rfc7736>.
[RFC7736]马，K，“内容交付网络互连（CDNI）媒体类型注册”，RFC 7736，DOI 10.17487/RFC7736，2015年12月<http://www.rfc-editor.org/info/rfc7736>.
Focusing on a main use case that contains a simple (yet somewhat challenging), realistic, and generally imaginable scenario can help narrow down the requirements for the CDNI FCI. To this end, the following (simplified) use case can help clarify the semantics of footprints and capabilities for CDNI. In particular, the intention of the use case is to clarify what information needs to be exchanged on the CDNI FCI, what types of information need to be supported in a mandatory fashion (and which types can be considered optional), and what types of information need to be updated with respect to a priori established CDNI contracts.
关注包含简单（但有点挑战性）、现实且通常可以想象的场景的主要用例可以帮助缩小CDNI FCI的需求范围。为此，以下（简化的）用例有助于澄清CDNI的封装外形和功能的语义。特别是，用例的意图是澄清哪些信息需要在CDNI FCI上交换，哪些类型的信息需要以强制方式支持（哪些类型可以视为可选），以及哪些类型的信息需要根据事先确定的CDNI合同进行更新。
Use case: A given uCDN has several dCDNs. It selects one dCDN for delivery protocol A and footprint 1 and another dCDN for delivery protocol B and footprint 1. The dCDN that serves delivery protocol B has a further, transitive (level-2) dCDN that serves delivery protocol B in a subset of footprint 1 where the first-level dCDN cannot serve delivery protocol B itself. What happens if capabilities change in the transitive level-2 dCDN that might affect how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN cannot serve delivery protocol B anymore)? How will these changes be conveyed to the uCDN? In particular, what information does the uCDN need to be able to select a new first-level dCDN, for either all of footprint 1 or only the subset of footprint 1 that the transitive level-2 dCDN served on behalf of the first-level dCDN?
用例：给定的uCDN有多个DCDN。它为传送协议A和封装外形1选择一个dCDN，为传送协议B和封装外形1选择另一个dCDN。为交付协议B提供服务的dCDN具有另一个可传递（2级）dCDN，该dCDN在封装外形1的子集中为交付协议B提供服务，其中第一级dCDN不能为交付协议B本身提供服务。如果可传递的2级dCDN中的功能发生变化，可能会影响uCDN选择1级dCDN的方式（例如，如果2级dCDN无法再为交付协议B提供服务），会发生什么情况？这些变更将如何传达给uCDN？特别是，uCDN需要什么信息才能为所有封装外形1或仅封装外形1的子集选择新的一级dCDN，可传递的二级dCDN代表一级dCDN服务？
Roughly speaking, "footprint" can be defined as a dCDN's "ability and willingness to serve". However, in addition to simple ability and willingness to serve, the uCDN could want additional information before deciding which dCDN to select, e.g., "how well" a given dCDN can actually serve a given end user request. The dCDN's ability and willingness to serve SHOULD be distinguished from the subjective qualitative measurement of how well it can serve a given end user request. One can imagine that such additional information is implicitly associated with a given footprint, due to contractual agreements, Service Level Agreements (SLAs), business relationships, or past perceptions of dCDN quality. As an alternative, such additional information could also be explicitly included with the given footprint.
粗略地说，“足迹”可以定义为dCDN的“服务能力和意愿”。然而，除了简单的服务能力和意愿之外，uCDN在决定选择哪个dCDN之前可能需要额外的信息，例如，“给定dCDN实际能够为给定的最终用户请求提供多好的服务”。dCDN的服务能力和意愿应与主观定性测量区分开来，主观定性测量是指dCDN能够为给定的最终用户请求提供多好的服务。可以想象，由于合同协议、服务级别协议（SLA）、业务关系或过去对dCDN质量的看法，此类附加信息与给定的足迹隐式关联。作为替代方案，此类附加信息也可以显式包含在给定的封装外形中。
It is reasonable to assume that a significant part of the actual footprint advertisement will occur out-of-band, prior to any CDNI FCI advertisement, with footprints defined in contractual agreements between participating CDNs. The reason for this assumption is that any contractual agreement is likely to contain specifics about the
合理的假设是，在任何CDNI FCI广告发布之前，实际足迹广告的很大一部分将发生在带外，且足迹在参与CDN之间的合同协议中定义。这一假设的原因是，任何合同协议都可能包含有关合同的细节
dCDN coverage (footprint) to which the contractual agreement applies. In particular, additional information to judge the delivery quality associated with a given dCDN footprint might be defined in contractual agreements, outside of the CDNI FCI. Further, one can assume that dCDN contractual agreements about the delivery quality associated with a given footprint will probably be based on high-level aggregated statistics and will not be too detailed.
合同协议适用的dCDN覆盖范围（足迹）。特别是，在CDNI FCI之外的合同协议中，可以定义用于判断与给定dCDN足迹相关的交付质量的附加信息。此外，可以假设关于给定足迹相关交付质量的dCDN合同协议可能基于高级汇总统计数据，不会太详细。
Given that a large part of the footprint advertisement will be defined in contractual agreements, the semantics of CDNI footprint advertisement refer to answering the following question: what exactly still needs to be advertised by the CDNI FCI? For instance, updates about temporal failures of part of a footprint can be useful information to convey via the CDNI Request Routing interface. Such information would provide updates on information previously agreed upon in contracts between the participating CDNs. In other words, the CDNI FCI is a means for a dCDN to provide changes/updates regarding a footprint it has previously agreed to serve in a contract with a uCDN.
鉴于大部分足迹广告将在合同协议中定义，CDNI足迹广告的语义指的是回答以下问题：CDNI FCI到底还需要宣传什么？例如，关于封装外形部分暂时故障的更新可以是通过CDNI请求路由接口传递的有用信息。此类信息将提供先前在参与CDN之间的合同中约定的信息的更新。换句话说，CDNI FCI是dCDN提供其先前同意在与uCDN的合同中服务的封装外形的变更/更新的一种手段。
Generally speaking, one can imagine two categories of footprints to be advertised by a dCDN:
一般来说，我们可以想象dCDN广告的两类足迹：
o A footprint could be defined based on coverage/reachability, where "coverage/reachability" refers to a set of prefixes, a geographic region, or similar boundary. The dCDN claims that it can cover/reach "end user requests coming from this footprint".
o 足迹可以基于覆盖率/可达性定义，其中“覆盖率/可达性”指一组前缀、地理区域或类似边界。dCDN声称它可以覆盖/达到“来自此封装外形的最终用户请求”。
o A footprint could be defined based on resources, where "resources" refers to Surrogates a dCDN claims to have (e.g., the location of Surrogates/resources). The dCDN claims that "from this footprint" it can serve incoming end user requests.
o 足迹可以基于资源定义，其中“资源”指dCDN声称拥有的代理（例如，代理/资源的位置）。dCDN声称“从这个足迹”它可以为传入的最终用户请求提供服务。
For each of these footprint types, there are capabilities associated with a given footprint:
对于每种封装外形类型，都有与给定封装外形相关的功能：
o capabilities such as delivery protocol, redirection mode, and metadata, which are supported in the coverage area for a footprint that is defined by coverage/reachability, or
o 功能，如交付协议、重定向模式和元数据，这些功能在由覆盖率/可达性定义的覆盖区中受支持，或
o capabilities of resources, such as delivery protocol, redirection mode, and metadata, which apply to a footprint that is defined by resources.
o 资源的功能，例如传递协议、重定向模式和元数据，它们应用于由资源定义的封装外形。
Resource footprint types are more specific than coverage/reachability footprint types, where the actual coverage and reachability are extrapolated from the resource location (e.g., a netmask applied to a resource IP address to derive an IP prefix). The specific methods
资源占用类型比覆盖率/可达性占用类型更具体，其中实际覆盖率和可达性是从资源位置推断出来的（例如，应用于资源IP地址以派生IP前缀的网络掩码）。具体方法
for extrapolating coverage/reachability from the resource location are beyond the scope of this document. In the degenerate case, the resource address could be specified as a coverage/reachability footprint type, in which case no extrapolation is necessary. Resource footprint types could expose the internal structure of a CDN; this could be undesirable. As such, the resource footprint types are not considered mandatory to support for CDNI.
从资源位置推断覆盖率/可达性超出了本文档的范围。在退化情况下，可以将资源地址指定为覆盖率/可达性足迹类型，在这种情况下，不需要外推。资源足迹类型可以公开CDN的内部结构；这可能是不可取的。因此，资源占用类型对于支持CDNI不是必需的。
Footprints can be viewed as constraints for delegating requests to a dCDN: a dCDN footprint advertisement tells the uCDN the limitations for delegating a request to the dCDN. For IP prefixes or ASN(s), the footprint signals to the uCDN that it should consider the dCDN a candidate only if the IP address of the Request Routing source falls within the prefix set (or ASN, respectively). The CDNI specifications do not define how a given uCDN determines what address ranges are in a particular ASN. Similarly, for country codes, a uCDN should only consider the dCDN a candidate if it covers the country of the Request Routing source. The CDNI specifications do not define how a given uCDN determines the country of the Request Routing source. Multiple footprint constraints are additive: the advertisement of different footprint types narrows the dCDN's candidacy cumulatively.
封装外形可以被视为将请求委派给dCDN的约束：dCDN封装外形广告告诉uCDN将请求委派给dCDN的限制。对于IP前缀或ASN（s），只有当请求路由源的IP地址分别位于前缀集（或ASN）中时，才能将UDN的足迹信号考虑到DCDN候选。CDNI规范没有定义给定uCDN如何确定特定ASN中的地址范围。类似地，对于国家代码，UCDN应该只考虑DCDN一个候选，如果它覆盖请求路由源的国家。CDNI规范没有定义给定uCDN如何确定请求路由源的国家/地区。多个封装外形约束是加性的：不同封装外形类型的广告逐渐缩小了dCDN的候选范围。
Independent of the exact type of a footprint, a footprint might also include the connectivity of a given dCDN to other CDNs that are able to serve content to users on behalf of that dCDN, to cover cases with cascaded CDNs. Further, the dCDN needs to be able to express its footprint to an interested uCDN in a comprehensive form, e.g., as a data set containing the complete footprint. However, making incremental updates to express dynamic changes in state is also desirable.
独立于封装外形的确切类型，封装外形还可能包括给定dCDN到其他CDN的连接，这些CDN能够代表该dCDN向用户提供内容，以覆盖级联CDN的情况。此外，dCDN需要能够以综合形式将其封装外形表示为感兴趣的uCDN，例如，作为包含完整封装外形的数据集。然而，进行增量更新以表示状态的动态变化也是可取的。
In general, the dCDN needs to be able to express its general capabilities to the uCDN. These general capabilities could indicate if the dCDN supports a given service -- for instance, HTTP vs. HTTPS delivery. Furthermore, the dCDN needs to be able to express particular capabilities for service delivery in a particular footprint area. For example, the dCDN might in general offer HTTPS but not in some specific areas, either for maintenance reasons or because the Surrogates covering this particular area cannot deliver this type of service. Hence, in certain cases a footprint and capabilities are tied together and cannot be interpreted independently of each other. In such cases, i.e., where capabilities need to be expressed on a per-footprint basis, it could be beneficial to combine footprint advertisement and capabilities advertisement.
通常，dCDN需要能够向uCDN表达其一般功能。这些通用功能可以指示dCDN是否支持给定的服务——例如HTTP与HTTPS交付。此外，dCDN需要能够在特定的占地面积内表达特定的服务交付功能。例如，dCDN通常可能会提供HTTPS，但在某些特定区域中不提供HTTPS，这可能是出于维护原因，也可能是因为覆盖此特定区域的代理无法提供此类服务。因此，在某些情况下，封装外形和功能是捆绑在一起的，不能相互独立解释。在这种情况下，也就是说，需要在每个封装外形的基础上表达能力的情况下，将封装外形广告和能力广告结合起来可能是有益的。
A high-level and very rough semantic for capabilities is thus the following: capabilities are types of information that allow a uCDN to determine if a dCDN is able (and willing) to accept (and properly handle) a delegated content request. In addition, capabilities are characterized by the fact that this information can change over time based on the state of the network or Surrogates.
因此，功能的高级和非常粗略的语义如下：功能是允许uCDN确定dCDN是否能够（并且愿意）接受（并正确处理）委托的内容请求的信息类型。此外，这些功能的特点是，这些信息可以根据网络或代理的状态随时间而变化。
At first glance, several broad categories of capabilities seem useful to convey via an advertisement interface; however, advertising capabilities that change highly dynamically (e.g., real-time delivery performance metrics, CDN resource load, or other highly dynamically changing QoS information) are beyond the scope of the CDNI FCI. First, out of the multitude of possible metrics and capabilities, it is hard to agree on a subset and the precise metrics to be used. Second, it seems infeasible to specify such highly dynamically changing capabilities and the corresponding metrics within a reasonable time frame.
乍一看，通过广告界面传达几大类功能似乎很有用；然而，高度动态变化的广告功能（例如，实时交付性能指标、CDN资源负载或其他高度动态变化的QoS信息）超出了CDNI FCI的范围。首先，在众多可能的指标和功能中，很难就要使用的子集和精确指标达成一致。其次，在合理的时间范围内指定这种高度动态变化的能力和相应的指标似乎是不可行的。
Useful capabilities refer to information that does not change highly dynamically and that, in many cases, is absolutely necessary for deciding on a particular dCDN for a given end user request. For instance, if an end user request concerns the delivery of a video file with a certain protocol, the uCDN needs to know if a given dCDN is capable of supporting this delivery protocol.
有用的功能指的是不会发生高度动态变化的信息，在许多情况下，这些信息对于确定给定最终用户请求的特定dCDN是绝对必要的。例如，如果最终用户请求涉及使用特定协议交付视频文件，则uCDN需要知道给定dCDN是否能够支持此交付协议。
Similar to footprint advertisement, it is reasonable to assume that a significant part of the actual (resource) capabilities advertisement will also occur out-of-band, prior to any CDNI FCI advertisement, with capabilities defined in contractual agreements between participating CDNs. The role of capability advertisement is hence rather to enable the dCDN to update a uCDN on changes since a contract has been set up (e.g., in case a new delivery protocol is suddenly being added to the list of supported delivery protocols of a given dCDN or in case a certain delivery protocol is suddenly not being supported anymore due to failures). "Capabilities advertisement" thus refers to conveying information to a uCDN about changes/updates to certain capabilities with respect to a given contract.
与footprint广告类似，合理的假设是，实际（资源）能力广告的很大一部分也将出现在带外，在任何CDNI FCI广告之前，其能力在参与CDN之间的合同协议中定义。因此，能力公告的作用是使dCDN能够在合同建立后的更改中更新uCDN（例如，如果新的传递协议突然被添加到给定dCDN的受支持传递协议列表中，或者如果某个传递协议由于故障而突然不再受支持）。“功能公告”因此，是指向uCDN传递有关给定合同的某些功能的更改/更新的信息。
Given these semantics, it needs to be decided what exact capabilities are useful and how these can be expressed. Since the details of CDNI contracts are not known at the time of this writing (and the CDNI interface is better off being agnostic to these contracts anyway), it remains to be seen what capabilities will be used to define agreements between CDNs in practice. One implication for standardization could be to initially only specify a very limited set of mandatory capabilities for advertisement and have, on top of that,
鉴于这些语义，需要确定哪些确切的功能是有用的，以及如何表达这些功能。由于在撰写本文时还不知道CDNI合同的细节（而且CDNI接口最好是对这些合同不可知），因此在实践中将使用什么功能来定义CDN之间的协议还有待观察。标准化的一个含义可能是最初只指定一组非常有限的广告强制性功能，除此之外，
a flexible data model that allows exchanging additional capabilities when needed. Still, agreement needs to be reached regarding which capabilities (if any) will be mandatory among CDNs.
灵活的数据模型，允许在需要时交换附加功能。不过，CDN之间需要就哪些功能（如果有）是强制性的达成一致。
It is not feasible to enumerate all the possible options for the mandatory capabilities listed above (e.g., all the potential delivery protocols or metadata options) or anticipate all the future needs for additional capabilities. FCI object extensibility is necessary to support future capabilities, as well as a generic protocol for conveying any capability information (e.g., with common encoding, error handling, and security mechanisms; further requirements for the CDNI FCI are listed in [RFC7337]).
列举上述强制性功能的所有可能选项（例如，所有潜在的交付协议或元数据选项）或预测未来对附加功能的所有需求是不可行的。FCI对象扩展性对于支持未来的功能以及用于传输任何功能信息的通用协议（例如，使用通用编码、错误处理和安全机制；CDNI FCI的进一步要求在[RFC7337]中列出）是必要的。
Acknowledgments
致谢
Jan Seedorf is partially supported by the GreenICN project (GreenICN: Architecture and Applications of Green Information Centric Networking), a research project supported jointly by the European Commission under its 7th Framework Program (contract no. 608518) and the National Institute of Information and Communications Technology (NICT) in Japan (contract no. 167). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the GreenICN project, the European Commission, or NICT.
Jan Sedorf得到了GreenICN项目（GreenICN：绿色信息中心网络的架构和应用）的部分支持，该项目由欧盟委员会第七框架计划（合同号608518）和日本国家信息和通信技术研究所（NICT）共同支持（第167号合同）。本文中包含的观点和结论是作者的观点和结论，不应被解释为必然代表GreenICN项目、欧盟委员会或NICT的官方政策或支持，无论明示或暗示。
Martin Stiemerling provided initial input to this document and valuable comments to the ongoing discussions among the authors of this document. Thanks to Francois Le Faucheur and Scott Wainner for providing valuable comments and suggestions for the text.
Martin Stiemerling为本文件提供了初步意见，并对本文件作者之间正在进行的讨论提出了宝贵意见。感谢Francois Le Faucheur和Scott Wainner为本文提供了宝贵的意见和建议。
Authors' Addresses
作者地址
Jan Seedorf HFT Stuttgart - University of Applied Sciences Stuttgart Schellingstrasse 24 Stuttgart 70174 Germany
简·西多夫HFT斯图加特-应用科学大学斯图加特谢灵斯特拉斯24斯图加特70174德国
Phone: +49-0711-8926-2801
Email: jan.seedorf@hft-stuttgart.de
Phone: +49-0711-8926-2801
Email: jan.seedorf@hft-stuttgart.de
Jon Peterson NeuStar 1800 Sutter St. Suite 570 Concord, CA 94520 United States of America
美国加利福尼亚州康科德市萨特街1800号乔恩·彼得森纽斯塔570室，邮编94520
Email: jon.peterson@neustar.biz
Email: jon.peterson@neustar.biz
Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144 Italy
Stefano Previdi Cisco Systems Via Del Serafico 200罗马0144意大利
Email: sprevidi@cisco.com
Email: sprevidi@cisco.com
Ray van Brandenburg TNO Anna van Buerenplein 1 The Hague 2595DA The Netherlands
荷兰海牙2595DA Ray van Brandenburg TNO Anna van Buerenplein 1
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl
Phone: +31-88-866-7000
Email: ray.vanbrandenburg@tno.nl
Kevin J. Ma Ericsson 43 Nagog Park Acton, MA 01720 United States of America
Kevin J.Ma Ericsson 43美国马萨诸塞州纳戈公园阿克顿01720
Phone: +1-978-844-5100
Email: kevin.j.ma@ericsson.com
Phone: +1-978-844-5100
Email: kevin.j.ma@ericsson.com