Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 6968 INRIA
Category: Experimental B. Adamson
ISSN: 2070-1721 Naval Research Laboratory
July 2013
Internet Engineering Task Force (IETF) V. Roca
Request for Comments: 6968 INRIA
Category: Experimental B. Adamson
ISSN: 2070-1721 Naval Research Laboratory
July 2013
FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols
FCAST：异步分层编码（ALC）和面向NACK的可靠多播（NORM）协议的对象交付
Abstract
摘要
This document introduces the FCAST reliable object (e.g., file) delivery application. It is designed to operate either on top of the underlying Asynchronous Layered Coding (ALC) / Layered Coding Transport (LCT) reliable multicast transport protocol or the NACK-Oriented Reliable Multicast (NORM) transport protocol.
本文档介绍FCAST可靠对象（例如文件）交付应用程序。它设计用于在底层异步分层编码（ALC）/分层编码传输（LCT）可靠多播传输协议或面向NACK的可靠多播（NORM）传输协议之上运行。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. 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/rfc6968.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6968.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Requirements Notation ......................................4
1.2. Definitions, Notations, and Abbreviations ..................5
2. FCAST Data Formats ..............................................6
2.1. Compound Object Format .....................................6
2.2. Carousel Instance Descriptor Format ........................9
3. FCAST Principles ...............................................12
3.1. FCAST Content Delivery Service ............................12
3.2. Compound Object and Metadata Transmission .................13
3.3. Metadata Content ..........................................13
3.4. Carousel Transmission .....................................15
3.5. Carousel Instance Descriptor Special Object ...............15
3.6. Compound Object Identification ............................17
3.7. FCAST Sender Behavior .....................................18
3.8. FCAST Receiver Behavior ...................................19
4. Requirements for Compliant Implementations .....................20
4.1. Requirements Related to the Object Metadata ...............20
4.2. Requirements Related to the Carousel Instance Descriptor ..21
5. Security Considerations ........................................22
5.1. Problem Statement .........................................22
5.2. Attacks against the Data Flow .............................22
5.2.1. Attacks Meant to Gain Access to
Confidential Objects ...............................23
5.2.2. Attacks Meant to Corrupt Objects ...................23
5.3. Attacks against the Session Control Parameters and
Associated Building Blocks ................................24
5.3.1. Attacks against the Session Description ............25
5.3.2. Attacks against the FCAST CID ......................25
5.3.3. Attacks against the Object Metadata ................25
5.3.4. Attacks against the ALC/LCT and NORM Parameters ....26
5.3.5. Attacks against the Associated Building Blocks .....26
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Definitions, Notations, and Abbreviations ..................5
2. FCAST Data Formats ..............................................6
2.1. Compound Object Format .....................................6
2.2. Carousel Instance Descriptor Format ........................9
3. FCAST Principles ...............................................12
3.1. FCAST Content Delivery Service ............................12
3.2. Compound Object and Metadata Transmission .................13
3.3. Metadata Content ..........................................13
3.4. Carousel Transmission .....................................15
3.5. Carousel Instance Descriptor Special Object ...............15
3.6. Compound Object Identification ............................17
3.7. FCAST Sender Behavior .....................................18
3.8. FCAST Receiver Behavior ...................................19
4. Requirements for Compliant Implementations .....................20
4.1. Requirements Related to the Object Metadata ...............20
4.2. Requirements Related to the Carousel Instance Descriptor ..21
5. Security Considerations ........................................22
5.1. Problem Statement .........................................22
5.2. Attacks against the Data Flow .............................22
5.2.1. Attacks Meant to Gain Access to
Confidential Objects ...............................23
5.2.2. Attacks Meant to Corrupt Objects ...................23
5.3. Attacks against the Session Control Parameters and
Associated Building Blocks ................................24
5.3.1. Attacks against the Session Description ............25
5.3.2. Attacks against the FCAST CID ......................25
5.3.3. Attacks against the Object Metadata ................25
5.3.4. Attacks against the ALC/LCT and NORM Parameters ....26
5.3.5. Attacks against the Associated Building Blocks .....26
5.4. Other Security Considerations .............................27
5.5. Minimum Security Recommendations ..........................27
6. Operational Considerations .....................................28
7. IANA Considerations ............................................29
7.1. Creation of the FCAST Object Metadata Format Registry .....29
7.2. Creation of the FCAST Object Metadata Encoding Registry ...30
7.3. Creation of the FCAST Object Metadata Types Registry ......30
8. Acknowledgments ................................................32
9. References .....................................................32
9.1. Normative References ......................................32
9.2. Informative References ....................................33
Appendix A. FCAST Examples ........................................35
A.1. Simple Compound Object Example .............................35
A.2. Carousel Instance Descriptor Example .......................36
Appendix B. Additional Metadata Transmission Mechanisms ...........37
B.1. Supporting Additional Mechanisms ...........................37
B.2. Using NORM_INFO Messages with FCAST/NORM ...................38
B.2.1. Example ................................................38
5.4. Other Security Considerations .............................27
5.5. Minimum Security Recommendations ..........................27
6. Operational Considerations .....................................28
7. IANA Considerations ............................................29
7.1. Creation of the FCAST Object Metadata Format Registry .....29
7.2. Creation of the FCAST Object Metadata Encoding Registry ...30
7.3. Creation of the FCAST Object Metadata Types Registry ......30
8. Acknowledgments ................................................32
9. References .....................................................32
9.1. Normative References ......................................32
9.2. Informative References ....................................33
Appendix A. FCAST Examples ........................................35
A.1. Simple Compound Object Example .............................35
A.2. Carousel Instance Descriptor Example .......................36
Appendix B. Additional Metadata Transmission Mechanisms ...........37
B.1. Supporting Additional Mechanisms ...........................37
B.2. Using NORM_INFO Messages with FCAST/NORM ...................38
B.2.1. Example ................................................38
This document introduces the FCAST reliable and scalable object (e.g., file) delivery application. Two variants of FCAST exist:
本文档介绍FCAST可靠且可扩展的对象（如文件）交付应用程序。FCAST有两种变体：
o FCAST/ALC, which relies on the Asynchronous Layered Coding (ALC) [RFC5775] and Layered Coding Transport (LCT) [RFC5651] reliable multicast transport protocol, and
o FCAST/ALC，它依赖于异步分层编码（ALC）[RFC5775]和分层编码传输（LCT）[RFC5651]可靠的多播传输协议，以及
o FCAST/NORM, which relies on the NACK-Oriented Reliable Multicast (NORM) [RFC5740] transport protocol.
o FCAST/NORM，它依赖于面向NACK的可靠多播（NORM）[RFC5740]传输协议。
Hereafter, the term "FCAST" denotes either FCAST/ALC or FCAST/NORM. FCAST is not a new protocol specification per se. Instead, it is a set of data format specifications and instructions on how to use ALC and NORM to implement a file-casting service.
此后，术语“FCAST”表示FCAST/ALC或FCAST/NORM。FCAST本身并不是一个新的协议规范。相反，它是一组关于如何使用ALC和NORM实现文件转换服务的数据格式规范和说明。
FCAST is expected to work in many different environments and is designed to be flexible. The service provided by FCAST can differ according to the exact conditions under which FCAST is used. For instance, the delivery service provided by FCAST might be fully reliable, or only partially reliable, depending upon the exact way FCAST is used. Indeed, if FCAST/ALC is used for a finite duration over purely unidirectional networks (where no feedback is possible), a fully reliable service may not be possible in practice. This is different with NORM, which can collect reception and loss feedback from receivers. This is discussed in Section 6.
FCAST预计可在许多不同的环境中工作，并且设计灵活。FCAST提供的服务可能因使用FCAST的确切条件而异。例如，FCAST提供的交付服务可能完全可靠，也可能仅部分可靠，具体取决于FCAST的使用方式。事实上，如果FCAST/ALC在纯单向网络上使用有限时间（不可能有反馈），则在实践中可能无法实现完全可靠的服务。这与NORM不同，NORM可以收集来自接收者的接收和丢失反馈。第6节对此进行了讨论。
The delivery service provided by FCAST might also differ in terms of scalability with respect to the number of receivers. The FCAST/ALC service is naturally massively scalable, since neither FCAST nor ALC limits the number of receivers (there is no feedback message at all). Conversely, the scalability of FCAST/NORM is typically limited by NORM itself, as NORM relies on feedback messages from the receivers. However, NORM is designed in such a way to offer a reasonably scalable service (e.g., through the use of proactive Forward Error Correction (FEC) codes [RFC6363]), and so does the service provided by FCAST/NORM. This aspect is also discussed in Section 6.
FCAST提供的交付服务在接收器数量方面的可伸缩性方面也可能有所不同。FCAST/ALC服务自然是可大规模扩展的，因为FCAST和ALC都不限制接收器的数量（根本没有反馈消息）。相反，FCAST/NORM的可伸缩性通常受到NORM本身的限制，因为NORM依赖于来自接收器的反馈消息。然而，NORM的设计方式是提供合理可扩展的服务（例如，通过使用主动前向纠错（FEC）码[RFC6363]），FCAST/NORM提供的服务也是如此。第6节也讨论了这一方面。
A design goal behind FCAST is to define a streamlined solution, in order to enable lightweight implementations of the protocol stack and to limit the operational processing and storage requirements. A consequence of this choice is that FCAST cannot be considered a versatile application capable of addressing all the possible use-cases. On the contrary, FCAST has some intrinsic limitations. From this point of view, it differs from the File Delivery over Unidirectional Transport (FLUTE) [RFC6726], which favors flexibility at the expense of some additional complexity.
FCAST背后的一个设计目标是定义一个简化的解决方案，以实现协议栈的轻量级实现，并限制操作处理和存储需求。这种选择的结果是FCAST不能被认为是一个能够处理所有可能用例的通用应用程序。相反，FCAST有一些固有的局限性。从这个角度来看，它不同于单向传输上的文件传递（FLUTE）[RFC6726]，后者以牺牲一些额外的复杂性为代价，支持灵活性。
A good example of the design choices meant to favor simplicity is the way FCAST manages the object metadata: by default, the metadata and the object content are sent together, in a Compound Object. This solution has many advantages in terms of simplicity, as will be described later on. However, this solution has an intrinsic limitation, since it does not enable a receiver to decide in advance, before beginning the reception of the Compound Object, whether the object is of interest or not, based on the information that may be provided in the metadata. Therefore, this document discusses additional techniques that may be used to mitigate this limitation. When use-cases require that each receiver download the whole set of objects sent in the session (e.g., with mirroring tools), this limitation is not considered a problem.
FCAST管理对象元数据的方式是有利于简化的设计选择的一个很好的例子：默认情况下，元数据和对象内容在一个复合对象中一起发送。此解决方案在简单性方面具有许多优点，稍后将对其进行描述。然而，该解决方案具有固有的限制，因为它不允许接收者在开始接收复合对象之前，基于元数据中可能提供的信息预先决定对象是否感兴趣。因此，本文件讨论了可用于缓解此限制的其他技术。当用例要求每个接收器下载会话中发送的整个对象集（例如，使用镜像工具）时，此限制不被视为问题。
Finally, Section 4 provides guidance for compliant implementation of the specification and identifies those features that are optional.
最后，第4节为规范的合规实施提供了指导，并确定了那些可选的特性。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses the following definitions:
本文件使用以下定义：
FCAST/ALC: denotes the FCAST application running on top of the ALC/LCT transport protocol.
FCAST/ALC：表示在ALC/LCT传输协议之上运行的FCAST应用程序。
FCAST/NORM: denotes the FCAST application running on top of the NORM transport protocol.
FCAST/NORM：表示在NORM传输协议之上运行的FCAST应用程序。
FCAST: denotes either FCAST/ALC or FCAST/NORM.
FCAST：表示FCAST/ALC或FCAST/NORM。
Compound Object: denotes an ALC or NORM transport object composed of the FCAST Header and the Object Data (some Compound Objects may not include any Object Data).
复合对象：表示由FCAST头和对象数据组成的ALC或NORM传输对象（某些复合对象可能不包括任何对象数据）。
FCAST Header: denotes the header prepended to the Object Data, which together form the Compound Object. This FCAST Header usually contains the object metadata, among other things.
FCAST Header：表示在对象数据前面加上的头，它们一起构成复合对象。此FCAST头通常包含对象元数据以及其他内容。
Object Data: denotes the original object (e.g., a file) that forms the payload of the Compound Object.
对象数据：表示构成复合对象有效负载的原始对象（例如文件）。
Carousel: denotes the building block that enables an FCAST sender to transmit Compound Objects in a cyclic manner.
转盘：表示使FCAST发送器能够以循环方式传输复合对象的构建块。
Carousel Instance: denotes a fixed set of registered Compound Objects that are sent by the carousel during a certain number of cycles. Whenever Compound Objects need to be added or removed, a new Carousel Instance is defined.
转盘实例：表示转盘在一定周期内发送的一组固定的已注册复合对象。每当需要添加或删除复合对象时，都会定义一个新的旋转木马实例。
Carousel Instance Descriptor (CID): denotes a special object that lists the Compound Objects that comprise a given Carousel Instance.
转盘实例描述符（CID）：表示一个特殊对象，该对象列出了组成给定转盘实例的复合对象。
Carousel Instance IDentifier (CIID): numeric value that identifies a Carousel Instance.
转盘实例标识符（CIID）：标识转盘实例的数值。
Carousel Cycle: denotes a transmission round within which all the Compound Objects registered in the Carousel Instance are transmitted a certain number of times. By default, Compound Objects are transmitted once per cycle, but higher values, which might differ on a per-object basis, are possible.
Carousel Cycle：表示一个传输循环，在该循环中，在Carousel实例中注册的所有复合对象被传输一定次数。默认情况下，复合对象每循环传输一次，但也可以使用更高的值（每个对象的值可能不同）。
Transport Object Identifier (TOI): denotes the numeric identifier associated with a specific object by the underlying transport protocol. In the case of ALC, this corresponds to the TOI described in [RFC5651]. In the case of NORM, this corresponds to the NormTransportId described in [RFC5740].
传输对象标识符（TOI）：表示通过基础传输协议与特定对象关联的数字标识符。对于ALC，这对应于[RFC5651]中描述的TOI。对于NORM，这对应于[RFC5740]中描述的NormTransportId。
FEC Object Transmission Information (FEC OTI): FEC information associated with an object and that is essential for the FEC decoder to decode a specific object.
FEC对象传输信息（FEC OTI）：与对象相关联的FEC信息，是FEC解码器解码特定对象所必需的信息。
This section details the various data formats used by FCAST.
本节详细介绍FCAST使用的各种数据格式。
In an FCAST session, Compound Objects are constructed by prepending the FCAST Header (which usually contains the metadata of the object) to the Object Data (see Section 3.2). Figure 1 illustrates the associated format. All multi-byte fields MUST be in network (Big Endian) byte order.
在FCAST会话中，复合对象是通过将FCAST头（通常包含对象的元数据）前置到对象数据（请参见第3.2节）来构建的。图1说明了相关的格式。所有多字节字段必须以网络（大端）字节顺序排列。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Ver |Resvd|G|C| MDFmt | MDEnc | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| FCAST Header Length | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| d
| Object Metadata (variable length) | r
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Padding (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| |
. Object Data (optional, variable length) .
. .
. .
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Ver |Resvd|G|C| MDFmt | MDEnc | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| FCAST Header Length | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| d
| Object Metadata (variable length) | r
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Padding (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
| |
. Object Data (optional, variable length) .
. .
. .
Figure 1: Compound Object Format
图1：复合对象格式
The FCAST Header fields are:
FCAST头字段包括：
+------------+------------------------------------------------------+
| Field | Description |
+------------+------------------------------------------------------+
| Version | 3-bit field that MUST be set to 0 in this |
| | specification and that indicates the FCAST protocol |
| | version number. |
| | |
| Reserved | 3-bit field that MUST be set to 0 in this |
| | specification and is reserved for future use. |
| | Receivers MUST ignore this field. |
| | |
| G | 1-bit field that, when set to 1, indicates that the |
| | checksum encompasses the whole Compound Object |
| | (Global checksum). When set to 0, this field |
| | indicates that the checksum encompasses only the |
| | FCAST Header. |
| | |
| C | 1-bit field that, when set to 1, indicates that the |
| | object is a CID. When set to 0, this field |
| | indicates that the transported object is a standard |
| | object. |
| | |
| Metadata | 4-bit field that defines the format of the Object |
| Format | Metadata field (see Section 7). An HTTP/1.1 |
| (MDFmt) | metainformation format [RFC2616] MUST be supported |
| | and is associated to value 0. Other formats (e.g., |
| | XML) may be defined in the future. |
| | |
| Metadata | 4-bit field that defines the optional encoding of |
| Encoding | the Object Metadata field (see Section 7). Two |
| (MDEnc) | values are currently defined. A value of 0 |
| | indicates that the field contains UTF-8 encoded |
| | [RFC3629] text. A value of 1 indicates that the |
| | field contains GZIP [RFC1952] compressed UTF-8 |
| | encoded text. |
| | |
+------------+------------------------------------------------------+
| Field | Description |
+------------+------------------------------------------------------+
| Version | 3-bit field that MUST be set to 0 in this |
| | specification and that indicates the FCAST protocol |
| | version number. |
| | |
| Reserved | 3-bit field that MUST be set to 0 in this |
| | specification and is reserved for future use. |
| | Receivers MUST ignore this field. |
| | |
| G | 1-bit field that, when set to 1, indicates that the |
| | checksum encompasses the whole Compound Object |
| | (Global checksum). When set to 0, this field |
| | indicates that the checksum encompasses only the |
| | FCAST Header. |
| | |
| C | 1-bit field that, when set to 1, indicates that the |
| | object is a CID. When set to 0, this field |
| | indicates that the transported object is a standard |
| | object. |
| | |
| Metadata | 4-bit field that defines the format of the Object |
| Format | Metadata field (see Section 7). An HTTP/1.1 |
| (MDFmt) | metainformation format [RFC2616] MUST be supported |
| | and is associated to value 0. Other formats (e.g., |
| | XML) may be defined in the future. |
| | |
| Metadata | 4-bit field that defines the optional encoding of |
| Encoding | the Object Metadata field (see Section 7). Two |
| (MDEnc) | values are currently defined. A value of 0 |
| | indicates that the field contains UTF-8 encoded |
| | [RFC3629] text. A value of 1 indicates that the |
| | field contains GZIP [RFC1952] compressed UTF-8 |
| | encoded text. |
| | |
| Checksum | 16-bit field that contains the checksum computed |
| | over either the whole Compound Object (when G is set |
| | to 1) or over the FCAST Header (when G is set to 0), |
| | using the Internet checksum algorithm specified in |
| | [RFC1071]. More precisely, the Checksum field is |
| | the 16-bit one's complement of the one's complement |
| | sum of all 16-bit words to be considered. If a |
| | segment contains an odd number of octets to be |
| | checksummed, the last octet is padded on the right |
| | with zeros to form a 16-bit word for checksum |
| | purposes (this pad is not transmitted). While |
| | computing the checksum, the Checksum field itself |
| | MUST be set to zero. |
| | |
| FCAST | 32-bit field indicating total length (in bytes) of |
| Header | all fields of the FCAST Header, except the optional |
| Length | padding. An FCAST Header Length field set to value |
| | 8 means that there is no metadata included. When |
| | this size is not a multiple of 32-bit words and when |
| | the FCAST Header is followed by non-null Object |
| | Data, padding MUST be added. It should be noted |
| | that the Object Metadata field maximum size is equal |
| | to (2^32 - 8) bytes. |
| | |
| Object | Variable-length field that contains the metadata |
| Metadata | associated to the object. The format and encoding |
| | of this field are defined by the MDFmt and MDEnc |
| | fields, respectively. With the default format and |
| | encoding, the Object Metadata field, if not empty, |
| | MUST contain UTF-8 encoded text that follows the |
| | "TYPE" ":" "VALUE" "<CR-LF>" format used in HTTP/1.1 |
| | for metainformation [RFC2616]. The various |
| | metadata items can appear in any order. The |
| | receiver MUST NOT assume that this string is NULL- |
| | terminated. When no metadata is communicated, this |
| | field MUST be empty and the FCAST Header Length MUST |
| | be equal to 8. |
| | |
| Padding | Optional, variable-length field of zero-value bytes |
| | to align the start of the Object Data to a 32-bit |
| | boundary. Padding is only used when the FCAST |
| | Header Length value, in bytes, is not a multiple of |
| | 4 and when the FCAST Header is followed by non-null |
| | Object Data. |
+------------+------------------------------------------------------+
| Checksum | 16-bit field that contains the checksum computed |
| | over either the whole Compound Object (when G is set |
| | to 1) or over the FCAST Header (when G is set to 0), |
| | using the Internet checksum algorithm specified in |
| | [RFC1071]. More precisely, the Checksum field is |
| | the 16-bit one's complement of the one's complement |
| | sum of all 16-bit words to be considered. If a |
| | segment contains an odd number of octets to be |
| | checksummed, the last octet is padded on the right |
| | with zeros to form a 16-bit word for checksum |
| | purposes (this pad is not transmitted). While |
| | computing the checksum, the Checksum field itself |
| | MUST be set to zero. |
| | |
| FCAST | 32-bit field indicating total length (in bytes) of |
| Header | all fields of the FCAST Header, except the optional |
| Length | padding. An FCAST Header Length field set to value |
| | 8 means that there is no metadata included. When |
| | this size is not a multiple of 32-bit words and when |
| | the FCAST Header is followed by non-null Object |
| | Data, padding MUST be added. It should be noted |
| | that the Object Metadata field maximum size is equal |
| | to (2^32 - 8) bytes. |
| | |
| Object | Variable-length field that contains the metadata |
| Metadata | associated to the object. The format and encoding |
| | of this field are defined by the MDFmt and MDEnc |
| | fields, respectively. With the default format and |
| | encoding, the Object Metadata field, if not empty, |
| | MUST contain UTF-8 encoded text that follows the |
| | "TYPE" ":" "VALUE" "<CR-LF>" format used in HTTP/1.1 |
| | for metainformation [RFC2616]. The various |
| | metadata items can appear in any order. The |
| | receiver MUST NOT assume that this string is NULL- |
| | terminated. When no metadata is communicated, this |
| | field MUST be empty and the FCAST Header Length MUST |
| | be equal to 8. |
| | |
| Padding | Optional, variable-length field of zero-value bytes |
| | to align the start of the Object Data to a 32-bit |
| | boundary. Padding is only used when the FCAST |
| | Header Length value, in bytes, is not a multiple of |
| | 4 and when the FCAST Header is followed by non-null |
| | Object Data. |
+------------+------------------------------------------------------+
The FCAST Header is then followed by the Object Data, i.e., either an original object (possibly encoded by FCAST) or a CID. Note that the length of the Object Data content is the ALC or NORM transported object length (e.g., as specified by the FEC OTI) minus the FCAST Header Length and optional padding, if any.
FCAST报头之后是对象数据，即原始对象（可能由FCAST编码）或CID。请注意，对象数据内容的长度是ALC或NORM传输对象长度（例如，由FEC OTI指定）减去FCAST头长度和可选填充（如果有）。
In an FCAST session, a CID MAY be sent in order to carry the list of Compound Objects that are part of a given Carousel Instance (see Section 3.5). The format of the CID that is sent as a special Compound Object is given in Figure 2. Being a special case of Compound Object, this format is in line with the format described in Section 2.1.
在FCAST会话中，可以发送CID以携带作为给定旋转木马实例一部分的复合对象列表（参见第3.5节）。作为特殊复合对象发送的CID的格式如图2所示。作为复合对象的特例，该格式与第2.1节中描述的格式一致。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Ver |Resvd|G|C| MDFmt | MDEnc | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| FCAST Header Length | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| d
| Object Metadata (variable length) | r
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Padding (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
. . ^
. Object List (variable length) . |
. . o
. +-+-+-+-+-+-+-+-+ b
. | j
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Ver |Resvd|G|C| MDFmt | MDEnc | Checksum | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| FCAST Header Length | h
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| d
| Object Metadata (variable length) | r
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | Padding (optional) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
. . ^
. Object List (variable length) . |
. . o
. +-+-+-+-+-+-+-+-+ b
. | j
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v
Figure 2: Carousel Instance Descriptor Format
图2:Carousel实例描述符格式
Because the CID is transmitted as a special Compound Object, the following CID-specific metadata entries are defined and MUST be supported:
由于CID作为特殊的复合对象传输，因此定义了以下特定于CID的元数据条目，并且必须支持这些条目：
o Fcast-CID-Complete: this is an optional entry that, when set to "Fcast-CID-Complete: 1", indicates no new object (if we ignore CID Compound Objects) in addition to the ones whose TOIs are listed in this CID or the ones that have been listed in the previous CID(s), will be sent in the future. Conversely, if it is set to "Fcast-CID-Complete: 0", or if this entry is absent, it indicates that the session is not complete. An FCAST sender MUST NOT use any other value for this entry.
o Fcast CID Complete（Fcast CID完成）：这是一个可选条目，当设置为“Fcast CID Complete:1”时，表示除其TOI在此CID中列出的对象或已在以前的CID中列出的对象外，未来不会发送任何新对象（如果我们忽略CID复合对象）。相反，如果将其设置为“Fcast CID Complete:0”，或者如果此条目不存在，则表示会话未完成。FCAST发送方不得对此条目使用任何其他值。
o Fcast-CID-ID: this entry contains the Carousel Instance IDentifier, or CIID. It starts from 0 upon FCAST session creation and is incremented by 1 for each new Carousel Instance. This entry is optional if the FCAST session consists of a single, complete Carousel Instance (no need for the FCAST sender to specify it and for the FCAST receiver to process it). In all other cases, this entry MUST be defined. In particular, the CIID is used by the TOI equivalence mechanism, thanks to which any object is uniquely identified, even if the TOI is updated (e.g., after re-enqueuing the object with NORM). The Fcast-CID-ID value can also be useful for detecting possible gaps in the Carousel Instances, for instance, gaps caused by long disconnection periods. Finally, it can also be useful for avoiding problems when TOI wrapping to 0 takes place to differentiate the various incarnations of the TOIs if need be.
o Fcast CID ID：此条目包含转盘实例标识符或CIID。在创建FCAST会话时，它从0开始，并为每个新的转盘实例递增1。如果FCAST会话包含一个完整的转盘实例（FCAST发送方无需指定，FCAST接收方无需处理），则此项是可选的。在所有其他情况下，必须定义此条目。特别是，CIID由TOI等价机制使用，由于该机制，任何对象都被唯一标识，即使TOI被更新（例如，在使用NORM重新排队对象之后）。Fcast CID ID值还可用于检测转盘实例中可能存在的间隙，例如，长时间断开连接导致的间隙。最后，如果需要的话，它还有助于避免将TOI包装为0以区分TOI的各种化身时出现问题。
The following standard metadata entry types are also used (Section 3.3):
还使用了以下标准元数据条目类型（第3.3节）：
o Content-Length: specifies the size in bytes of the Object List, before any content encoding (if any).
o 内容长度：指定对象列表在任何内容编码（如果有）之前的大小（以字节为单位）。
o Content-Encoding: specifies the optional encoding of the Object List, performed by FCAST.
o 内容编码：指定对象列表的可选编码，由FCAST执行。
An empty Object List is valid and indicates that the current Carousel Instance does not include any objects (Section 3.5). This can be specified by using the following metadata entry:
空对象列表是有效的，表示当前旋转木马实例不包括任何对象（第3.5节）。这可以通过使用以下元数据项来指定：
Content-Length: 0
内容长度：0
or simply by leaving the Object List empty. In both cases, padding MUST NOT be used, and consequently the ALC or NORM transported object length (e.g., as specified by the FEC OTI) minus the FCAST Header Length equals zero.
或者简单地将对象列表留空。在这两种情况下，不得使用填充，因此ALC或NORM传输对象长度（例如，由FEC OTI指定）减去FCAST头长度等于零。
The Object List, when non-empty and with MDEnc=0, is UTF-8-encoded text that is not necessarily NULL-terminated. It can contain two things:
当对象列表非空且MDEnc=0时，它是UTF-8编码的文本，不一定以NULL结尾。它可以包含两个方面：
o a list of TOI values, and
o TOI值列表，以及
o a list of TOI equivalences.
o TOI等价物列表。
A list of TOIs included in the current Carousel Instance is specified as an ASCII string containing comma-delimited individual TOI values and/or TOI intervals. Individual TOIs consist of a single integer value, while TOI intervals are a hyphen-delimited pair of TOI values
当前转盘实例中包含的TOI列表指定为ASCII字符串，其中包含逗号分隔的单个TOI值和/或TOI间隔。单个TOI由单个整数值组成，而TOI间隔是一对以连字符分隔的TOI值
to indicate an inclusive range of TOI values (e.g., "1,2,4-6" would indicate the list of TOI values of 1, 2, 4, 5, and 6). For a TOI interval indicated by "TOI_a-TOI_b", the "TOI_a" value MUST be strictly inferior to the "TOI_b" value. If a TOI wrapping to 0 occurs in an interval, then two TOI intervals MUST be specified: TOI_a-MAX_TOI and 0-TOI_b.
表示TOI值的包含范围（例如，“1,2,4-6”表示TOI值的列表为1,2,4,5和6）。对于“TOI_a-TOI_b”指示的TOI间隔，“TOI_a”值必须严格低于“TOI_b”值。如果在一个时间间隔内将TOI换行为0，则必须指定两个TOI时间间隔：TOI_a-MAX_TOI和0-TOI_b。
This string can also contain the TOI equivalences, if any. The format is a comma-separated list of equivalence TOI value pairs with a delimiting equals sign '=' to indicate the equivalence assignment (e.g., " newTOI "=" 1stTOI "/" 1stCIID "). Each equivalence indicates that the new TOI, for the current Carousel Instance, is equivalent to (i.e., refers to the same object as) the provided identifier, 1stTOI, for the Carousel Instance of ID 1stCIID. In the case of the NORM protocol, where NormTransportId values need to monotonically increase for NACK-based protocol operation, this allows an object from a prior Carousel Instance to be relisted in a subsequent Carousel Instance with the receiver set informed of the equivalence so that unnecessary retransmission requests can be avoided.
此字符串还可以包含TOI等价项（如果有）。该格式是以逗号分隔的等价TOI值对列表，用等号“=”表示等价分配（例如，“newTOI”=“1stTOI”/“1stCIID”）。每个等价表示当前旋转木马实例的新TOI等价于（即，引用与相同的对象）为ID为1stCIID的旋转木马实例提供的标识符1stTOI。在NORM协议的情况下，其中NormTransportId值需要为基于NACK的协议操作而单调增加，这允许来自先前旋转木马实例的对象在随后的旋转木马实例中重新列出，并且接收器集被告知等价性，以便可以避免不必要的重传请求。
The ABNF [RFC5234] is as follows:
ABNF[RFC5234]如下所示：
cid-list = *(list-elem *( "," list-elem))
list-elem = toi-elem / toieq-elem
toi-elem = toi-value / toi-interval
toi-value = 1*DIGIT
toi-interval = toi-value "-" toi-value
; additionally, the first toi-value MUST be
; strictly inferior to the second toi-value
toieq-elem = "(" toi-value "=" toi-value "/" ciid-value ")"
ciid-value = 1*DIGIT
DIGIT = %x30-39
; a digit between 0 and 9, inclusive
cid-list = *(list-elem *( "," list-elem))
list-elem = toi-elem / toieq-elem
toi-elem = toi-value / toi-interval
toi-value = 1*DIGIT
toi-interval = toi-value "-" toi-value
; additionally, the first toi-value MUST be
; strictly inferior to the second toi-value
toieq-elem = "(" toi-value "=" toi-value "/" ciid-value ")"
ciid-value = 1*DIGIT
DIGIT = %x30-39
; a digit between 0 and 9, inclusive
For readability purposes and to simplify processing, the TOI values in the list MUST be given in increasing order, handling wrap of the TOI space appropriately. TOI equivalence elements MUST be grouped together at the end of the list in increasing newTOI order. Specifying a TOI equivalence for a given newTOI relieves the sender from specifying newTOI explicitly in the TOI list. A receiver MUST be able to handle situations where the same TOI appears both in the TOI value and TOI equivalence lists. Finally, a given TOI value or TOI equivalence item MUST NOT be included multiple times in either list.
为了便于阅读和简化处理，列表中的TOI值必须按递增顺序给出，并适当处理TOI空间的换行。TOI等价元素必须按递增的NETOI顺序分组在列表末尾。为给定的newTOI指定TOI等价物可以免除发送方在TOI列表中显式指定newTOI的麻烦。接收方必须能够处理相同TOI同时出现在TOI值和TOI等价列表中的情况。最后，给定的TOI值或TOI等效项不得多次包含在任一列表中。
For instance, the following Object List specifies that the current Carousel Instance is composed of 8 objects, and that TOIs 100 to 104 are equivalent to TOIs 10 to 14 of Carousel Instance ID 2 and refer to the same objects:
例如，以下对象列表指定当前旋转木马实例由8个对象组成，且TOI 100至104相当于旋转木马实例ID 2的TOI 10至14，并引用相同的对象：
97,98,99,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2)
97,98,99,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2)
or equivalently:
或相当于：
97-104,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2)
97-104,(100=10/2),(101=11/2),(102=12/2),(103=13/2),(104=14/2)
This section details the principles of FCAST.
本节详细介绍了FCAST的原理。
The basic goal of FCAST is to transmit objects to a group of receivers in a reliable way, where the receiver set may be restricted to a single receiver or may include possibly a very large number of receivers. FCAST supports two forms of operation:
FCAST的基本目标是以可靠的方式将对象发送到一组接收机，其中接收机集可以限制为单个接收机，或者可能包括非常多的接收机。FCAST支持两种形式的操作：
1. FCAST/ALC, where the FCAST application works on top of the ALC/LCT reliable multicast transport protocol, without any feedback from the receivers, and
1. FCAST/ALC，其中FCAST应用程序在ALC/LCT可靠多播传输协议之上工作，没有来自接收器的任何反馈，以及
2. FCAST/NORM, where the FCAST application works on top of the NORM transport protocol, which requires positive/negative acknowledgments from the receivers.
2. FCAST/NORM，其中FCAST应用程序在NORM传输协议之上工作，该协议需要来自接收器的肯定/否定确认。
This specification is designed such that both forms of operation share as much commonality as possible. Section 6 discusses some operational aspects and the content delivery service that is provided by FCAST for a given use-case.
本规范的设计使两种操作形式尽可能具有共同性。第6节讨论了一些操作方面以及FCAST为给定用例提供的内容交付服务。
FCAST carries metadata elements by prepending them to the object they refer to. As a result, a Compound Object is created that is composed of an FCAST Header followed by the Object Data (Figure 3). This header is itself composed of the object metadata (if any) as well as several fields (e.g., to indicate format, encoding, or boundaries (Section 2.1)).
FCAST通过将元数据元素前置到它们所引用的对象来携带元数据元素。结果，创建了一个复合对象，它由FCAST头和对象数据组成（图3）。此标头本身由对象元数据（若有）和几个字段（例如，用于指示格式、编码或边界（第2.1节））组成。
<------------------------ Compound Object ----------------------->
+-------------------------+--------------------------------------+
| FCAST Header | Object Data |
| (can include metadata) | (can be encoded by FCAST) |
+-------------------------+--------------------------------------+
<------------------------ Compound Object ----------------------->
+-------------------------+--------------------------------------+
| FCAST Header | Object Data |
| (can include metadata) | (can be encoded by FCAST) |
+-------------------------+--------------------------------------+
Figure 3: Compound Object Composition
图3：复合对象组合
Attaching the metadata to the object is an efficient solution, since it guarantees that metadata are received along with the associated object, and it allows the transport of the metadata to benefit from any transport-layer erasure protection of the Compound Object (e.g., using FEC encoding and/or NACK-based repair). However, a limit of this scheme is that a client does not know the metadata of an object before beginning its reception, and in the case of erasures affecting the metadata, not until the object decoding is completed. The details of course depend upon the transport protocol and the FEC code used.
将元数据附加到对象是一个有效的解决方案，因为它保证元数据与相关对象一起接收，并且它允许元数据的传输受益于复合对象的任何传输层擦除保护（例如，使用FEC编码和/或基于NACK的修复）。然而，该方案的限制是，客户端在开始接收对象之前不知道对象的元数据，并且在影响元数据的擦除情况下，直到对象解码完成。当然，细节取决于所使用的传输协议和FEC代码。
Appendix B describes extensions that provide additional means to carry metadata, e.g., to communicate metadata ahead of time.
附录B描述了一些扩展，这些扩展提供了携带元数据的额外手段，例如提前传递元数据。
The following metadata types are defined in [RFC2616]:
[RFC2616]中定义了以下元数据类型：
o Content-Location: the URI of the object, which gives the name and location of the object.
o 内容位置：对象的URI，它给出了对象的名称和位置。
o Content-Type: a string that contains the MIME type of the object.
o 内容类型：包含对象MIME类型的字符串。
o Content-Length: an unsigned 64-bit integer that contains the size in bytes of the initial object, before any content encoding (if any) and without considering the FCAST Header. Note that the use of certain FEC schemes MAY further limit the maximum value of the object.
o 内容长度：一个无符号的64位整数，包含初始对象的字节大小，在任何内容编码（如果有）之前，且不考虑FCAST头。注意，某些FEC方案的使用可能进一步限制对象的最大值。
o Content-Encoding: a string that contains the optional encoding of the object performed by FCAST. For instance:
o 内容编码：包含FCAST执行的对象可选编码的字符串。例如：
Content-Encoding: gzip
内容编码：gzip
indicates that the object has been encoded with GZIP [RFC1952]. If there is no Content-Encoding entry, the receiver MUST assume that FCAST did not modify the original encoding of the object (default).
指示已使用GZIP[RFC1952]对对象进行编码。如果没有内容编码条目，接收方必须假定FCAST没有修改对象的原始编码（默认）。
The following additional metadata types are defined to check object integrity:
定义以下其他元数据类型以检查对象完整性：
o Fcast-Obj-Digest-SHA256: a string that contains the "base64" [RFC4648] encoding of the SHA-256 message digest of the object [RFC3174] [RFC6234], before any content encoding is applied (if any) and without considering the FCAST Header. This digest is meant to protect from transmission and processing errors, not from deliberate attacks by an intelligent attacker (see Section 5). This digest only protects the object, not the header, and therefore not the metadata. A separate checksum is provided for that purpose (Section 2.1).
o Fcast-Obj-Digest-SHA256：在应用任何内容编码（如果有）之前且不考虑Fcast头，包含对象[RFC3174][RFC6234]的SHA-256消息摘要的“base64”[RFC4648]编码的字符串。本摘要旨在防止传输和处理错误，而不是智能攻击者的蓄意攻击（参见第5节）。此摘要仅保护对象，而不保护标头，因此不保护元数据。为此提供了单独的校验和（第2.1节）。
o Fcast-Obj-Digest-SHA1: similar to Fcast-Obj-Digest-SHA256, except that SHA-256 is replaced by SHA-1. An FCAST sender MAY include both an Fcast-Obj-Digest-SHA1 and an Fcast-Obj-Digest-SHA256 message digest in the metadata, in order to let a receiver select the most appropriate algorithm (e.g., depending on local processing power).
o Fcast-Obj-Digest-SHA1：与Fcast-Obj-Digest-SHA256类似，只是SHA-256被SHA-1替换。FCAST发送方可以在元数据中包括FCAST-Obj-Digest-SHA1和FCAST-Obj-Digest-SHA256消息摘要，以便让接收方选择最合适的算法（例如，取决于本地处理能力）。
The following additional metadata types are used for dealing with very large objects (e.g., objects that largely exceed the working memory of a receiver). When this happens, the metadata associated to each sub-object MUST include the following entries:
以下附加元数据类型用于处理非常大的对象（例如，大大超过接收器工作内存的对象）。发生这种情况时，与每个子对象关联的元数据必须包括以下条目：
o Fcast-Obj-Slice-Nb: an unsigned 32-bit integer that contains the total number of slices. A value greater than 1 indicates that this object is the result of a split of the original object.
o Fcast Obj Slice Nb：包含切片总数的无符号32位整数。大于1的值表示此对象是原始对象分割的结果。
o Fcast-Obj-Slice-Idx: an unsigned 32-bit integer that contains the slice index (in the {0 .. SliceNb - 1} interval).
o Fcast Obj Slice Idx：包含切片索引的无符号32位整数（在{0..SliceNb-1}间隔内）。
o Fcast-Obj-Slice-Offset: an unsigned 64-bit integer that contains the offset at which this slice starts within the original object.
o Fcast Obj切片偏移量：一个无符号64位整数，包含原始对象中此切片开始的偏移量。
Future IANA assignments to extend the set of metadata types supported by FCAST are to be made through Expert Review [RFC5226].
未来，扩展FCAST支持的元数据类型集的IANA分配将通过专家评审[RFC5226]进行。
A set of FCAST Compound Objects scheduled for transmission is considered a logical "Carousel". A given "Carousel Instance" is comprised of a fixed set of Compound Objects. Whenever the FCAST application needs to add new Compound Objects to or remove old Compound Objects from the transmission set, a new Carousel Instance is defined, since the set of Compound Objects changes. Because of the native object multiplexing capability of both ALC and NORM, a sender and receiver(s) are both capable of multiplexing and demultiplexing FCAST Compound Objects.
计划传输的一组FCAST复合对象被视为逻辑“转盘”。给定的“旋转木马实例”由一组固定的复合对象组成。每当FCAST应用程序需要向传输集中添加新的复合对象或从传输集中删除旧的复合对象时，都会定义一个新的旋转木马实例，因为复合对象集会发生更改。由于ALC和NORM的本机对象复用能力，发送方和接收方都能够复用和解复用FCAST复合对象。
For a given Carousel Instance, one or more transmission cycles are possible. During each cycle, all of the Compound Objects comprising the carousel are sent. By default, each object is transmitted once per cycle. However, in order to allow different levels of priority, some objects MAY be transmitted more often than others during a cycle and/or benefit from higher FEC protection than others. For example, this can be the case for the CID objects (Section 3.5), where extra protection can benefit overall carousel integrity. For some FCAST usage (e.g., a unidirectional "push" mode), a Carousel Instance may be sent in a single transmission cycle. In other cases, it may be conveyed in a large number of transmission cycles (e.g., in "on-demand" mode, where objects are made available for download during a long period of time).
对于给定的转盘实例，一个或多个传输周期是可能的。在每个周期中，组成转盘的所有复合对象都被发送。默认情况下，每个对象每个周期传输一次。然而，为了允许不同的优先级，一些对象可能在一个周期中比其他对象更频繁地传输，和/或受益于比其他对象更高的FEC保护。例如，CID对象（第3.5节）就是这种情况，在这种情况下，额外的保护有利于整个转盘的完整性。对于某些FCAST使用（例如，单向“推送”模式），可以在单个传输周期中发送转盘实例。在其他情况下，可在大量传输周期中传送（例如，在“按需”模式下，其中对象在较长时间内可供下载）。
The FCAST sender can transmit an OPTIONAL CID. The CID carries the list of the Compound Objects that are part of a given Carousel Instance by specifying their respective Transport Object Identifiers (TOIs). However, the CID does not describe the objects themselves (i.e., there is no metadata). Additionally, the CID MAY include an "Fcast-CID-Complete: 1" metadata entry to indicate that no further modification to the enclosed list will be done in the future. Finally, the CID MAY include a Carousel Instance ID (CIID) that identifies the Carousel Instance it pertains to. These aspects are discussed in Section 2.2.
FCAST发送器可以发送可选的CID。CID通过指定其各自的传输对象标识符（TOI），携带作为给定旋转木马实例一部分的复合对象列表。但是，CID不描述对象本身（即，没有元数据）。此外，CID可能包括“Fcast CID Complete:1”元数据条目，以指示将来不会对所附列表进行进一步修改。最后，CID可以包括识别其所属的转盘实例的转盘实例ID（CIID）。第2.2节讨论了这些方面。
There is no reserved TOI value for the CID Compound Object itself, since this special object is regarded by ALC/LCT or NORM as a standard object. On the contrary, the nature of this object (CID) is indicated by means of a specific FCAST Header field (the "C" flag from Figure 1) so that it can be recognized and processed by the FCAST application as needed. A direct consequence is that since a receiver does not know in advance which TOI will be used for the following CID (in the case of a dynamic session), it MUST NOT filter
CID复合对象本身没有保留TOI值，因为此特殊对象被ALC/LCT或NORM视为标准对象。相反，该对象（CID）的性质通过特定的FCAST头字段（图1中的“C”标志）表示，以便FCAST应用程序可以根据需要识别和处理它。一个直接的结果是，由于接收器事先不知道将为以下CID使用哪个TOI（在动态会话的情况下），因此它不能进行过滤
out packets that are not in the current CID's TOI list. Said differently, the goal of the CID is not to set up ALC or NORM packet filters (this mechanism would not be secure in any case).
输出不在当前CID的TOI列表中的数据包。换句话说，CID的目标不是设置ALC或NORM数据包过滤器（这种机制在任何情况下都不安全）。
The use of a CID remains OPTIONAL. If it is not used, then the clients progressively learn what files are part of the Carousel Instance by receiving ALC or NORM packets with new TOIs. However, using a CID has several benefits:
CID的使用仍然是可选的。如果未使用，则客户端通过接收带有新TOI的ALC或NORM数据包，逐步了解哪些文件是转盘实例的一部分。但是，使用CID有几个好处：
o When an "Fcast-CID-Complete" metadata entry set to "Fcast-CID-Complete: 1" is included, the receivers know when they can leave the session, i.e., when they have received all the objects that are part of the last Carousel Instance of this delivery session.
o 当包含设置为“Fcast CID Complete:1”的“Fcast CID Complete”元数据条目时，接收方知道何时可以离开会话，即何时已接收到作为此传递会话最后一个转盘实例一部分的所有对象。
o In the case of a session with a dynamic set of objects, the sender can reliably inform the receivers that some objects have been removed from the carousel with the CID. This solution is more robust than the Close Object "B" flag of ALC/LCT, since a client with intermittent connectivity might lose all the packets containing this "B" flag. And while NORM provides a robust object cancellation mechanism in the form of its NORM_CMD(SQUELCH) message in response to receiver NACK repair requests, the use of the CID provides an additional means for receivers to learn of objects for which it is futile to request repair.
o 在具有一组动态对象的会话的情况下，发送方可以可靠地通知接收方某些对象已使用CID从转盘中移除。此解决方案比ALC/LCT的Close Object“B”标志更健壮，因为具有间歇性连接的客户端可能会丢失包含此“B”标志的所有数据包。虽然NORM以其NORM_CMD（SQUELCH）消息的形式提供了一种健壮的对象取消机制，以响应接收器NACK修复请求，但CID的使用为接收器提供了一种额外的方法，以了解请求修复无效的对象。
o The TOI equivalence (Section 3.6) is signaled within the CID.
o TOI等效性（第3.6节）在CID内发出信号。
During idle periods, when the Carousel Instance does not contain any object, a CID with an empty TOI list MAY be transmitted. In that case, a new Carousel Instance ID MUST be used to differentiate this (empty) Carousel Instance from the other ones. This mechanism can be useful to inform the receivers that:
在空闲期间，当转盘实例不包含任何对象时，可以传输具有空TOI列表的CID。在这种情况下，必须使用新的转盘实例ID来区分此（空）转盘实例与其他实例。该机制可用于通知接收者：
o all the previously sent objects have been removed from the carousel. This therefore improves the robustness of FCAST even during "idle" periods.
o 以前发送的所有对象都已从传送带中删除。因此，即使在“空闲”期间，这也提高了FCAST的健壮性。
o the session is still active even if there is currently no content being sent. Said differently, it can be used as a heartbeat mechanism. If no "Fcast-CID-Complete" metadata entry is included (or if set to "Fcast-CID-Complete: 0"), it informs the receivers that the Carousel Instance may be modified and that new objects could be sent in the future.
o 即使当前没有发送任何内容，会话仍处于活动状态。换言之，它可以用作心跳机制。如果未包含“Fcast CID Complete”元数据条目（或如果设置为“Fcast CID Complete:0”），则会通知接收者可能会修改转盘实例，并且将来可能会发送新对象。
The FCAST Compound Objects are directly associated with the object-based transport service that the ALC and NORM protocols provide. In each protocol, the packets containing transport object content are labeled with a numeric transport object identifier: the TOI with ALC, and the NormTransportId with NORM. For the purposes of this document, this identifier in either case (ALC or NORM) is referred to as the TOI.
FCAST复合对象与ALC和NORM协议提供的基于对象的传输服务直接关联。在每个协议中，包含传输对象内容的数据包都使用数字传输对象标识符进行标记：TOI使用ALC，NormTransportId使用NORM。在本文件中，该标识符在任何情况下（ALC或NORM）均称为TOI。
There are several differences between ALC and NORM:
ALC和NORM之间存在一些差异：
o ALC's use of the TOI is rather flexible, since several TOI field sizes are possible (from 16 to 112 bits); since this size can be changed at any time, on a per-packet basis; and since the management of the TOI is totally free as long as each object is associated to a unique TOI (if no wraparound occurred).
o ALC对TOI的使用相当灵活，因为可以使用几种TOI字段大小（从16位到112位）；因为这个大小可以在任何时候改变，在每个包的基础上；而且，由于TOI的管理是完全免费的，只要每个对象都与唯一的TOI相关联（如果没有发生环绕）。
o NORM's use of the TOI serves a more "directive" purpose, since the TOI field is 16 bits long and since TOIs MUST be managed sequentially.
o NORM对TOI的使用更具有“指导性”的目的，因为TOI字段是16位长的，并且必须按顺序管理TOI。
In both NORM and ALC, it is possible that the transport identification space eventually wraps for long-lived sessions (especially with NORM, where this phenomenon is expected to happen more frequently). This can possibly introduce some ambiguity in FCAST object identification if a sender retains some older objects in newer Carousel Instances with updated object sets. To avoid ambiguity, the active TOIs (i.e., the TOIs corresponding to objects being transmitted) can only occupy half of the TOI sequence space. If an old object whose TOI has fallen outside the current window needs to be transmitted again, a new TOI must be used for it. In the case of NORM, this constraint limits to 32768 the maximum number of objects that can be part of any Carousel Instance.
在NORM和ALC中，传输标识空间最终可能会为长寿命会话（特别是在NORM中，这种现象预计会更频繁地发生）。如果发送方使用更新的对象集在较新的旋转木马实例中保留一些较旧的对象，这可能会在FCAST对象标识中引入一些模糊性。为了避免歧义，活动TOI（即，与正在传输的对象相对应的TOI）只能占用TOI序列空间的一半。如果TOI已超出当前窗口的旧对象需要再次传输，则必须为其使用新的TOI。在NORM的情况下，此约束将可以作为任何旋转木马实例一部分的最大对象数限制为32768。
In order to allow receivers to properly combine the transport packets with a newly assigned TOI to those associated to the previously assigned TOI, a mechanism is required to equate the objects with the new and the old TOIs. This mechanism consists of signaling, within the CID, that the newly assigned TOI for the current Carousel Instance is equivalent to the TOI used within a previous Carousel Instance. By convention, the reference tuple for any object is the {TOI; CIID} tuple used for its first transmission within a Carousel Instance. This tuple MUST be used whenever a TOI equivalence is provided. Section 2.2 details how to describe these TOI equivalences.
为了允许接收机将具有新分配的TOI的传输分组正确地组合到与先前分配的TOI相关联的那些分组，需要一种机制将对象与新的和旧的TOI等同起来。该机制包括在CID内发出信号，表明当前转盘实例的新分配TOI与前一个转盘实例中使用的TOI等效。按照约定，任何对象的引用元组都是在转盘实例中用于其第一次传输的{TOI；CIID}元组。每当提供TOI等价时，必须使用此元组。第2.2节详细说明了如何描述这些TOI等价物。
This section provides an informative description of expected FCAST sender behavior. The following operations can take place at a sender:
本节提供预期FCAST发送者行为的信息性描述。以下操作可以在发件人处进行：
1. The user (or another application) selects a set of objects (e.g., files) to deliver and submits them, along with their metadata, to the FCAST application.
1. 用户（或另一个应用程序）选择一组对象（例如，文件）进行交付，并将其连同元数据一起提交给FCAST应用程序。
2. For each object, FCAST creates the Compound Object and registers it in the Carousel Instance.
2. 对于每个对象，FCAST创建复合对象并将其注册到旋转木马实例中。
3. The user then informs FCAST that all the objects of the set have been submitted. If the user knows that no new object will be submitted in the future (i.e., if the session's content is now complete), the user informs FCAST. Finally, the user specifies how many transmission cycles are desired (this number may be infinite).
3. 然后，用户通知FCAST集合的所有对象都已提交。如果用户知道将来不会提交新对象（即，如果会话内容现在已完成），则用户会通知FCAST。最后，用户指定需要多少传输周期（这个数字可能是无限的）。
4. At this point, the FCAST application knows the full list of Compound Objects that are part of the Carousel Instance and can create a CID if desired, possibly with "Fcast-CID-Complete: 1" if no new objects will be sent in the future.
4. 此时，FCAST应用程序知道作为旋转木马实例一部分的复合对象的完整列表，如果需要，可以创建CID，如果将来不发送新对象，则可能使用“FCAST CID Complete:1”。
5. The FCAST application can now define a transmission schedule of these Compound Objects, including the optional CID. This schedule defines in which order the packets of the various Compound Objects should be sent. This document does not specify any scheme. This is left to the developer within the provisions of the underlying ALC or NORM protocol used and the knowledge of the target use-case.
5. FCAST应用程序现在可以定义这些复合对象的传输计划，包括可选的CID。此计划定义了各种复合对象的数据包的发送顺序。本文件未规定任何方案。这由开发人员根据所使用的底层ALC或NORM协议的规定以及目标用例的知识来决定。
6. The FCAST application then starts the carousel transmission, for the number of cycles specified. Transmissions take place until:
6. 然后，FCAST应用程序按照指定的循环数启动转盘传输。传输持续到：
* the desired number of transmission cycles has been reached, or
* 已达到所需的变速箱循环次数，或
* the user wants to prematurely stop the transmissions, or
* 用户希望提前停止传输，或
* the user wants to add one or several new objects to the carousel, or on the contrary wants to remove old objects from the carousel. In that case, a new Carousel Instance must be created.
* 用户希望向旋转木马添加一个或多个新对象，或者相反，希望从旋转木马中删除旧对象。在这种情况下，必须创建一个新的转盘实例。
7. If the session is not finished, then continue at Step 1 above.
7. 如果会话未完成，则继续上面的步骤1。
This section provides an informative description of expected FCAST receiver behavior. The following operations can take place at a receiver:
本节提供预期FCAST接收器行为的详细说明。以下操作可在接收器上进行：
1. The receiver joins the session and collects incoming packets.
1. 接收方加入会话并收集传入的数据包。
2. If the header portion of a Compound Object is entirely received (which may happen before receiving the entire object with some ALC/NORM configurations), or if the metadata is sent by means of another mechanism prior to the object, the receiver processes the metadata and chooses whether or not to continue to receive the object content.
2. 如果完全接收到复合对象的报头部分（这可能发生在接收具有某些ALC/NORM配置的整个对象之前），或者如果在对象之前通过另一种机制发送元数据，则接收方处理元数据并选择是否继续接收对象内容。
3. When a Compound Object has been entirely received, the receiver processes the header, retrieves the object metadata, perhaps decodes the metadata, and processes the object accordingly.
3. 当完全接收到一个复合对象时，接收方处理报头，检索对象元数据，可能解码元数据，并相应地处理对象。
4. When a CID is received, as indicated by the "C" flag set in the FCAST Header, the receiver decodes the CID and retrieves the list of objects that are part of the current Carousel Instance. This list can be used to remove objects sent in a previous Carousel Instance that might not have been totally decoded and that are no longer part of the current Carousel Instance.
4. 当接收到CID时，如FCAST头中设置的“C”标志所示，接收器解码CID并检索作为当前转盘实例一部分的对象列表。此列表可用于删除在以前的旋转木马实例中发送的对象，这些对象可能尚未完全解码，并且不再是当前旋转木马实例的一部分。
5. When a CID is received, the receiver also retrieves the list of TOI equivalences, if any, and takes appropriate measures, for instance, by informing the transport layer.
5. 当接收到CID时，接收器还检索TOI等价物的列表（如果有的话），并采取适当的措施，例如，通知传输层。
6. When a receiver receives a CID with an "Fcast-CID-Complete" metadata entry set to "Fcast-CID-Complete: 1" and has successfully received all the objects of the current Carousel Instance, it can safely exit from the current FCAST session.
6. 当接收器接收到“Fcast CID Complete”元数据条目设置为“Fcast CID Complete:1”的CID并成功接收到当前转盘实例的所有对象时，它可以安全地退出当前Fcast会话。
7. Otherwise, continue at Step 2 above.
7. 否则，继续上面的步骤2。
This section lists the features that any compliant FCAST/ALC or FCAST/NORM implementation MUST support, and those that remain OPTIONAL, e.g., in order to enable some optimizations for a given use-case, at a receiver.
本节列出了任何兼容FCAST/ALC或FCAST/NORM实现必须支持的功能，以及那些仍然是可选的功能，例如，为了在接收器上为给定用例启用某些优化。
Metadata transmission mechanisms:
元数据传输机制：
+------------------+------------------------------------------------+
| Feature | Status |
+------------------+------------------------------------------------+
| metadata | An FCAST sender MUST send metadata with the |
| transmission | in-band mechanism provided by FCAST, i.e., |
| using FCAST's | within the FCAST Header. All the FCAST |
| in-band | receivers MUST be able to process metadata |
| mechanism | sent with this FCAST in-band mechanism. |
| | |
| metadata | In addition to the FCAST in-band transmission |
| transmission | of metadata, an FCAST sender MAY send a subset |
| using other | or all of the metadata using another |
| mechanisms | mechanism. Supporting this mechanism in a |
| | compliant FCAST receiver is OPTIONAL, and its |
| | use is OPTIONAL too. An FCAST receiver MAY |
| | support this mechanism and take advantage of |
| | the metadata sent in this way. If that is |
| | not the case, the FCAST receiver will receive |
| | and process metadata sent in-band anyway. |
| | See Appendix B. |
+------------------+------------------------------------------------+
+------------------+------------------------------------------------+
| Feature | Status |
+------------------+------------------------------------------------+
| metadata | An FCAST sender MUST send metadata with the |
| transmission | in-band mechanism provided by FCAST, i.e., |
| using FCAST's | within the FCAST Header. All the FCAST |
| in-band | receivers MUST be able to process metadata |
| mechanism | sent with this FCAST in-band mechanism. |
| | |
| metadata | In addition to the FCAST in-band transmission |
| transmission | of metadata, an FCAST sender MAY send a subset |
| using other | or all of the metadata using another |
| mechanisms | mechanism. Supporting this mechanism in a |
| | compliant FCAST receiver is OPTIONAL, and its |
| | use is OPTIONAL too. An FCAST receiver MAY |
| | support this mechanism and take advantage of |
| | the metadata sent in this way. If that is |
| | not the case, the FCAST receiver will receive |
| | and process metadata sent in-band anyway. |
| | See Appendix B. |
+------------------+------------------------------------------------+
Metadata format and encoding:
元数据格式和编码：
+-----------------+-------------------------------------------------+
| Feature | Status |
+-----------------+-------------------------------------------------+
| Metadata Format | All FCAST implementations MUST support an |
| (MDFmt field) | HTTP/1.1 metainformation format [RFC2616]. |
| | |
| Metadata | All FCAST implementations MUST support both |
| Encoding (MDEnc | UTF-8 encoded text and GZIP compressed |
| field) | [RFC1952] UTF-8 encoded text for the Object |
| | Metadata field. |
+-----------------+-------------------------------------------------+
+-----------------+-------------------------------------------------+
| Feature | Status |
+-----------------+-------------------------------------------------+
| Metadata Format | All FCAST implementations MUST support an |
| (MDFmt field) | HTTP/1.1 metainformation format [RFC2616]. |
| | |
| Metadata | All FCAST implementations MUST support both |
| Encoding (MDEnc | UTF-8 encoded text and GZIP compressed |
| field) | [RFC1952] UTF-8 encoded text for the Object |
| | Metadata field. |
+-----------------+-------------------------------------------------+
Metadata items (Section 3.3):
元数据项（第3.3节）：
+-------------------------------+-----------------------------------+
| Feature | Status |
+-------------------------------+-----------------------------------+
| Content-Location | MUST be supported. |
| | |
| Content-Type | MUST be supported. |
| | |
| Content-Length | MUST be supported. |
| | |
| Content-Encoding | MUST be supported. All FCAST |
| | implementations MUST support GZIP |
| | encoding [RFC1952]. |
| | |
| Fcast-Obj-Digest-SHA1 | MUST be supported. |
| | |
| Fcast-Obj-Digest-SHA256 | MUST be supported. |
| | |
| Fcast-Obj-Slice-Nb | MUST be supported. |
| | |
| Fcast-Obj-Slice-Idx | MUST be supported. |
| | |
| Fcast-Obj-Slice-Offset | MUST be supported. |
+-------------------------------+-----------------------------------+
+-------------------------------+-----------------------------------+
| Feature | Status |
+-------------------------------+-----------------------------------+
| Content-Location | MUST be supported. |
| | |
| Content-Type | MUST be supported. |
| | |
| Content-Length | MUST be supported. |
| | |
| Content-Encoding | MUST be supported. All FCAST |
| | implementations MUST support GZIP |
| | encoding [RFC1952]. |
| | |
| Fcast-Obj-Digest-SHA1 | MUST be supported. |
| | |
| Fcast-Obj-Digest-SHA256 | MUST be supported. |
| | |
| Fcast-Obj-Slice-Nb | MUST be supported. |
| | |
| Fcast-Obj-Slice-Idx | MUST be supported. |
| | |
| Fcast-Obj-Slice-Offset | MUST be supported. |
+-------------------------------+-----------------------------------+
Any compliant FCAST implementation MUST support the CID mechanism, in order to list the Compound Objects that are part of a given Carousel Instance. However, its use is OPTIONAL.
任何兼容的FCAST实现都必须支持CID机制，以便列出作为给定旋转木马实例一部分的复合对象。但是，它的使用是可选的。
CID-specific Metadata items (Section 2.2):
CID特定元数据项（第2.2节）：
+--------------------+--------------------+
| Feature | Status |
+--------------------+--------------------+
| Fcast-CID-Complete | MUST be supported. |
| Fcast-CID-ID | MUST be supported. |
+--------------------+--------------------+
+--------------------+--------------------+
| Feature | Status |
+--------------------+--------------------+
| Fcast-CID-Complete | MUST be supported. |
| Fcast-CID-ID | MUST be supported. |
+--------------------+--------------------+
A content delivery system may be subject to attacks that target:
内容交付系统可能会受到以下攻击：
o the network, to compromise the delivery infrastructure (e.g., by creating congestion),
o 网络，以破坏交付基础设施（例如，通过造成拥塞），
o the Content Delivery Protocol (CDP), to compromise the delivery mechanism (i.e., FCAST in this case), or
o 内容交付协议（CDP），以破坏交付机制（即在本例中为FCAST），或
o the content itself, to corrupt the objects being transmitted.
o 内容本身，以损坏正在传输的对象。
These attacks can be launched against all or any subset of the following:
可以针对以下所有或任何子集发起这些攻击：
o the data flow itself (e.g., by sending forged packets),
o 数据流本身（例如，通过发送伪造数据包），
o the session control parameters sent either in-band or out-of-band (e.g., by corrupting the session description, the CID, the object metadata, or the ALC/LCT control parameters), or
o 带内或带外发送的会话控制参数（例如，通过破坏会话描述、CID、对象元数据或ALC/LCT控制参数），或
o some associated building blocks (e.g., the congestion control component).
o 一些相关的构建块（例如，拥塞控制组件）。
More details on these possible attacks are provided in the following sections, along with possible countermeasures. Recommendations are made in Section 5.5.
以下部分提供了有关这些可能攻击的更多详细信息，以及可能的对策。第5.5节提出了建议。
The following types of attacks against the data flow exist:
存在以下针对数据流的攻击类型：
o attacks that are meant to gain unauthorized access to a confidential object (e.g., obtaining non-free content without purchasing it) and
o 旨在获得对机密对象的未经授权访问的攻击（例如，在不购买的情况下获取非免费内容），以及
o attacks that try to corrupt the object being transmitted (e.g., to inject malicious code within an object, or to prevent a receiver from using an object; this would be a denial-of-service (DoS) attack).
o 试图破坏正在传输的对象的攻击（例如，在对象内注入恶意代码，或阻止接收者使用对象；这将是拒绝服务（DoS）攻击）。
Modern cryptographic mechanisms can provide access control to transmitted objects. One way to do this is by encrypting the entire object prior to transmission, knowing that authenticated receivers have the cryptographic mechanisms to decrypt the content. Another way is to encrypt individual packets using IPsec/ESP [RFC4303] (see also Section 5.5). These two techniques can also provide confidentiality to the objects being transferred.
现代密码机制可以提供对传输对象的访问控制。一种方法是在传输之前对整个对象进行加密，知道经过身份验证的接收者具有解密内容的加密机制。另一种方法是使用IPsec/ESP[RFC4303]加密单个数据包（另请参见第5.5节）。这两种技术还可以为正在传输的对象提供机密性。
If access control and/or confidentiality services are desired, one of these mechanisms is RECOMMENDED and SHOULD be deployed.
如果需要访问控制和/或保密服务，建议使用其中一种机制，并应进行部署。
Protection against attacks on the data integrity of the object may be achieved by a mechanism agreed upon between the sender and receiver that features sender authentication and a method to verify that the object integrity has remained intact during transmission. This service can be provided at the object level, but in that case a receiver has no way to identify what symbols are corrupted if the object is detected as corrupted. This service can also be provided at the packet level. In some cases, after removing all corrupted packets, the object may be recovered. Several techniques can provide data integrity and sender authentication services:
针对对象的数据完整性的攻击的保护可以通过发送方和接收方之间约定的机制来实现，该机制具有发送方认证和验证对象完整性在传输期间保持完整的方法。可以在对象级别提供此服务，但在这种情况下，如果检测到对象已损坏，则接收器无法识别哪些符号已损坏。也可以在分组级别提供该服务。在某些情况下，删除所有损坏的数据包后，可以恢复对象。有几种技术可以提供数据完整性和发送方身份验证服务：
o At the object level, the object can be digitally signed, for instance, by using RSASSA-PKCS1-v1_5 [RFC3447]. This signature enables a receiver to check the object integrity. Even if digital signatures are computationally expensive, this calculation occurs only once per object, which is usually acceptable.
o 在对象级别，可以使用RSASSA-PKCS1-v1_5[RFC3447]等对对象进行数字签名。此签名使接收者能够检查对象的完整性。即使数字签名在计算上很昂贵，但每个对象只进行一次计算，这通常是可以接受的。
o At the packet level, each packet can be digitally signed [RFC6584]. A major limitation is the high computational and transmission overheads that this solution requires.
o 在数据包级别，每个数据包都可以进行数字签名[RFC6584]。一个主要的限制是该解决方案需要较高的计算和传输开销。
o At the packet level, a Group-keyed Message Authentication Code (MAC) [RFC2104] [RFC6584] scheme can be used, for instance, by using HMAC-SHA-256 with a secret key shared by all the group members, senders, and receivers. This technique creates a cryptographically secured digest of a packet that is sent along with the packet itself. The Group-keyed MAC scheme does not create prohibitive processing loads or transmission overhead, but it has a major limitation: it only provides a group authentication/integrity service, since all group members share the same secret group key; this means that each member can send a forged packet. It is therefore restricted to situations where
o 在分组级别上，可以使用组密钥消息认证码（MAC）[RFC2104][RFC6584]方案，例如，通过使用HMAC-SHA-256以及由所有组成员、发送方和接收方共享的密钥。这种技术创建一个加密安全的数据包摘要，该摘要与数据包本身一起发送。组密钥MAC方案不会产生禁止性的处理负载或传输开销，但它有一个主要限制：它只提供组认证/完整性服务，因为所有组成员共享相同的秘密组密钥；这意味着每个成员都可以发送伪造的数据包。因此，它仅限于以下情况：
group members are fully trusted, or in association with another technique as a preliminary check to quickly detect attacks initiated by non-group members and to discard their packets.
组成员完全受信任，或与另一种技术相关联，作为初步检查，以快速检测非组成员发起的攻击并丢弃其数据包。
o At the packet level, Timed Efficient Stream Loss-Tolerant Authentication (TESLA) [RFC4082] [RFC5776] is an attractive solution that is robust to losses, provides an authentication and integrity verification service, and does not create any prohibitive processing load or transmission overhead. Yet, a delay is incurred in checking a TESLA authenticated packet; this delay may be more than what is desired in some use-cases.
o 在数据包级别，定时高效流丢失容忍认证（TESLA）[RFC4082][RFC5776]是一个具有吸引力的解决方案，它对丢失具有鲁棒性，提供认证和完整性验证服务，并且不会产生任何禁止性的处理负载或传输开销。然而，在检查特斯拉认证的数据包时会产生延迟；这种延迟可能比某些用例中所期望的要多。
o At the packet level, IPsec/ESP [RFC4303] can be used to check the integrity and authenticate the sender of all the packets being exchanged in a session (see Section 5.5).
o 在数据包级别，IPsec/ESP[RFC4303]可用于检查会话中交换的所有数据包的完整性并对发送方进行身份验证（见第5.5节）。
Techniques relying on public key cryptography (digital signatures and TESLA during the bootstrap process, when used) require that public keys be securely associated to the entities. This can be achieved via a Public Key Infrastructure (PKI), a Pretty Good Privacy (PGP) Web of Trust, or by securely preplacing the public keys of each group member.
依靠公钥加密技术（使用引导过程中的数字签名和特斯拉）的技术要求公钥与实体安全关联。这可以通过公钥基础设施（PKI）、相当好的隐私（PGP）信任网或安全地预先放置每个组成员的公钥来实现。
Techniques relying on symmetric key cryptography (Group-keyed MAC) require that a secret key be shared by all group members. This can be achieved by means of a group key management protocol or simply by securely preplacing the secret key (but this manual solution has many limitations).
依赖对称密钥加密（组密钥MAC）的技术要求所有组成员共享密钥。这可以通过组密钥管理协议或简单地通过安全地预先放置密钥来实现（但此手动解决方案有许多限制）。
It is up to the developer and deployer, who know the security requirements and features of the target application area, to define which solution is the most appropriate. In any case, whenever there is a threat of object corruption, it is RECOMMENDED that at least one of these techniques be used. Section 5.5 defines minimum security recommendations that can be used to provide such services.
由了解目标应用程序领域的安全需求和特性的开发人员和部署人员来定义哪种解决方案最合适。在任何情况下，只要存在对象损坏的威胁，建议至少使用其中一种技术。第5.5节定义了可用于提供此类服务的最低安全建议。
5.3. Attacks against the Session Control Parameters and Associated Building Blocks
5.3. 对会话控制参数和相关构建块的攻击
Let us now consider attacks against the session control parameters and the associated building blocks. The attacker can target, among other things, the following:
现在让我们考虑对会话控制参数和相关的构建块的攻击。除其他外，攻击者可以针对以下目标：
o the session description,
o 会话描述，
o the FCAST CID,
o FCAST CID，
o the metadata of an object,
o 对象的元数据，
o the ALC/LCT parameters, carried within the LCT header, or
o LCT标头中携带的ALC/LCT参数，或
o the FCAST associated building blocks, for instance, the multiple rate congestion control protocol.
o FCAST相关的构建块，例如，多速率拥塞控制协议。
The consequences of these attacks are potentially serious, since they can compromise the behavior of the content delivery system or even compromise the network itself.
这些攻击的后果可能很严重，因为它们可能会危害内容交付系统的行为，甚至危害网络本身。
An FCAST receiver may potentially obtain an incorrect session description for the session. The consequence is that legitimate receivers with the wrong session description will be unable to correctly receive the session content or will inadvertently try to receive at a much higher rate than they are capable of, thereby possibly disrupting other traffic in the network.
FCAST接收器可能会获取不正确的会话描述。其结果是，具有错误会话描述的合法接收器将无法正确接收会话内容，或将无意中尝试以远高于其能力的速率接收，从而可能中断网络中的其他通信。
To avoid these problems, it is RECOMMENDED that measures be taken to prevent receivers from accepting incorrect session descriptions. One such measure is sender authentication to ensure that receivers only accept legitimate session descriptions from authorized senders. How these measures are achieved is outside the scope of this document, since this session description is usually carried out-of-band.
为了避免这些问题，建议采取措施防止接收者接受错误的会话描述。其中一个措施是发送方身份验证，以确保接收方只接受来自授权发送方的合法会话描述。如何实现这些措施超出了本文件的范围，因为本课程描述通常在带外进行。
Corrupting the FCAST CID is one way to create a DoS attack. For example, the attacker can insert an "Fcast-CID-Complete: 1" metadata entry to make the receivers believe that no further modification will be done.
破坏FCAST CID是造成DoS攻击的一种方法。例如，攻击者可以插入“Fcast CID Complete:1”元数据条目，使接收者相信不会进行进一步修改。
It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity of the CID. To that purpose, one of the countermeasures mentioned above (Section 5.2.2) SHOULD be used. These measures will either be applied at the packet level or globally over the whole CID object. When there is no packet-level integrity verification scheme, it is RECOMMENDED to digitally sign the CID.
因此，建议采取措施保证完整性并检查CID的发送者身份。为此，应采用上述对策之一（第5.2.2节）。这些度量要么在数据包级别应用，要么在整个CID对象上全局应用。当没有数据包级完整性验证方案时，建议对CID进行数字签名。
Modifying the object metadata is another way to launch an attack. For example, the attacker may change the message digest associated to an object, leading a receiver to reject an object even if it has been correctly received. More generally, a receiver SHOULD be very careful during metadata processing. For instance, a receiver SHOULD NOT try to follow links (e.g., the URI contained in the
修改对象元数据是发起攻击的另一种方式。例如，攻击者可能会更改与对象关联的消息摘要，导致接收方拒绝对象，即使该对象已正确接收。更一般地说，接收方在元数据处理过程中应该非常小心。例如，接收方不应尝试跟踪链接（例如，包含在
Content-Location metadata). As another example, malformed HTTP content can be used as an attack vector, and a receiver should take great care with such content.
内容位置元数据）。作为另一个例子，畸形HTTP内容可以用作攻击向量，接收者应该非常小心地使用这些内容。
It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the identity of the sender of the Compound Object. To that purpose, one of the countermeasures mentioned above (Section 5.2.2) SHOULD be used. These measures will either be applied at the packet level or globally over the whole Compound Object. When there is no packet-level integrity verification scheme, it is RECOMMENDED to digitally sign the Compound Object.
因此，建议采取措施保证复合对象的完整性，并检查复合对象发送者的身份。为此，应采用上述对策之一（第5.2.2节）。这些度量要么在包级别应用，要么在整个复合对象上全局应用。当没有数据包级完整性验证方案时，建议对复合对象进行数字签名。
By corrupting the ALC/LCT header (or header extensions), one can execute attacks on the underlying ALC/LCT implementation. For example, sending forged ALC packets with the Close Session "A" flag set to 1 can lead the receiver to prematurely close the session. Similarly, sending forged ALC packets with the Close Object "B" flag set to 1 can lead the receiver to prematurely give up the reception of an object. The same comments can be made for NORM.
通过破坏ALC/LCT头（或头扩展），可以对底层ALC/LCT实现执行攻击。例如，发送关闭会话“A”标志设置为1的伪造ALC数据包可能导致接收器过早关闭会话。类似地，发送关闭对象“B”标志设置为1的伪造ALC分组可导致接收器过早地放弃接收对象。对于NORM，也可以做出同样的评论。
It is therefore RECOMMENDED that measures be taken to guarantee the integrity and to check the sender's identity in each ALC or NORM packet received. To that purpose, one of the countermeasures mentioned above (Section 5.2.2) SHOULD be used.
因此，建议采取措施保证完整性，并检查收到的每个ALC或NORM数据包中的发送者身份。为此，应采用上述对策之一（第5.2.2节）。
Let us first focus on the congestion control building block that may be used in an ALC or NORM session. A receiver with an incorrect or corrupted implementation of the multiple rate congestion control building block may affect the health of the network in the path between the sender and the receiver and may also affect the reception rates of other receivers who joined the session.
让我们首先关注可能在ALC或NORM会话中使用的拥塞控制构建块。具有多速率拥塞控制构建块的不正确或损坏的实现的接收器可能会影响发送方和接收器之间路径中的网络健康，并且还可能会影响加入会话的其他接收器的接收速率。
When congestion control is applied with FCAST, it is therefore RECOMMENDED that receivers be authenticated as legitimate receivers before they can join the session. If authenticating a receiver does not prevent that receiver from launching an attack, the network operator will still be able to easily identify the receiver that launched the attack and take countermeasures. The details of how this is done are outside the scope of this document.
当使用FCAST应用拥塞控制时，因此建议在加入会话之前，将接收器验证为合法接收器。如果对接收者进行身份验证不能阻止该接收者发起攻击，则网络运营商仍将能够轻松识别发起攻击的接收者并采取对策。如何完成此操作的详细信息不在本文档的范围内。
When congestion control is applied with FCAST, it is also RECOMMENDED that a packet-level authentication scheme be used, as explained in Section 5.2.2. Some of them, like TESLA, only provide a delayed authentication service, whereas congestion control requires a rapid
当使用FCAST应用拥塞控制时，还建议使用数据包级认证方案，如第5.2.2节所述。它们中的一些，如特斯拉，只提供延迟认证服务，而拥塞控制则需要快速响应
reaction. It is therefore RECOMMENDED [RFC5775] that a receiver using TESLA quickly reduce its subscription level when the receiver believes that congestion did occur, even if the packet has not yet been authenticated. Therefore, TESLA will not prevent DoS attacks where an attacker makes the receiver believe that congestion occurred. This is an issue for the receiver, but this will not compromise the network. Other authentication methods that do not feature this delayed authentication might be preferable, or a Group-keyed MAC scheme could be used in parallel with TESLA to prevent attacks launched from outside of the group.
反应因此，建议[RFC5775]使用特斯拉的接收器在认为确实发生了拥塞时快速降低其订阅级别，即使数据包尚未通过身份验证。因此，特斯拉不会阻止DoS攻击，因为攻击者会让接收者相信发生了拥塞。这是接收器的问题，但不会影响网络。不具有此延迟认证特征的其他认证方法可能更可取，或者组密钥MAC方案可与TESLA并行使用，以防止从组外发起的攻击。
Lastly, we note that the security considerations that apply to, and are described in, ALC [RFC5775], LCT [RFC5651], NORM [RFC5740], and FEC [RFC5052] also apply to FCAST, as FCAST builds on those specifications. In addition, any security considerations that apply to any congestion control building block used in conjunction with FCAST also apply to FCAST. Finally, the security discussion of [RMT-SEC] also applies here.
最后，我们注意到，适用于ALC[RFC5775]、LCT[RFC5651]、NORM[RFC5740]和FEC[RFC5052]并在其中描述的安全注意事项也适用于FCAST，因为FCAST建立在这些规范的基础上。此外，适用于与FCAST一起使用的任何拥塞控制构建块的任何安全注意事项也适用于FCAST。最后，[RMT-SEC]的安全性讨论也适用于此。
We now introduce a security configuration that is mandatory to implement but not necessarily mandatory to use, in the sense of [RFC3365]. Since FCAST/ALC relies on ALC/LCT, it inherits the "baseline secure ALC operation" of [RFC5775]. Similarly, since FCAST/NORM relies on NORM, it inherits the "baseline secure NORM operation" of [RFC5740]. Therefore, IPsec/ESP in transport mode MUST be implemented, but not necessarily used, in accordance with [RFC5775] and [RFC5740]. [RFC4303] explains that ESP can be used to potentially provide confidentiality, data origin authentication, content integrity, anti-replay, and (limited) traffic flow confidentiality. [RFC5775] specifies that the data origin authentication, content integrity, and anti-replay services SHALL be used, and that the confidentiality service is RECOMMENDED. If a short-lived session MAY rely on manual keying, it is also RECOMMENDED that an automated key management scheme be used, especially in the case of long-lived sessions.
现在，我们引入了一种安全配置，在[RFC3365]的意义上，该配置必须实现，但不一定必须使用。由于FCAST/ALC依赖于ALC/LCT，因此它继承了[RFC5775]的“基线安全ALC操作”。类似地，由于FCAST/NORM依赖于NORM，因此它继承了[RFC5740]的“基线安全NORM操作”。因此，必须按照[RFC5775]和[RFC5740]实现但不一定使用传输模式下的IPsec/ESP。[RFC4303]解释了ESP可用于潜在地提供机密性、数据源身份验证、内容完整性、反重播和（有限的）流量机密性。[RFC5775]规定应使用数据源身份验证、内容完整性和防重播服务，并建议使用保密服务。如果短寿命会话可能依赖于手动密钥，则还建议使用自动密钥管理方案，尤其是在长寿命会话的情况下。
Therefore, the RECOMMENDED solution for FCAST provides per-packet security, with data origin authentication, integrity verification, and anti-replay. This is sufficient to prevent most of the in-band attacks listed above. If confidentiality is required, a per-packet encryption SHOULD also be used.
因此，推荐的FCAST解决方案提供了每个数据包的安全性，包括数据源身份验证、完整性验证和反重播。这足以防止上面列出的大多数带内攻击。如果需要保密，还应使用每包加密。
FCAST is compatible with any congestion control protocol designed for ALC/LCT or NORM. However, depending on the use-case, the data flow generated by the FCAST application might not be constant but might instead be bursty in nature. Similarly, depending on the use-case, an FCAST session might be very short. Whether and how this will impact the congestion control protocol is out of the scope of the present document.
FCAST兼容为ALC/LCT或NORM设计的任何拥塞控制协议。但是，根据用例的不同，FCAST应用程序生成的数据流可能不是恒定的，而是突发性的。类似地，根据用例的不同，FCAST会话可能非常短。这是否以及如何影响拥塞控制协议不在本文件的范围之内。
FCAST is compatible with any security mechanism designed for ALC/LCT or NORM. The use of a security scheme is strongly RECOMMENDED (see Section 5).
FCAST与为ALC/LCT或NORM设计的任何安全机制兼容。强烈建议使用安全方案（见第5节）。
FCAST is compatible with any FEC scheme designed for ALC/LCT or NORM. Whether FEC is used or not, and the kind of FEC scheme used, are to some extent transparent to FCAST.
FCAST与为ALC/LCT或NORM设计的任何FEC方案兼容。无论是否使用FEC，以及使用的FEC方案的种类，在某种程度上对FCAST是透明的。
FCAST is compatible with both IPv4 and IPv6. Nothing in the FCAST specification has any implication on the source or destination IP address type.
FCAST与IPv4和IPv6兼容。FCAST规范中的任何内容都不会影响源或目标IP地址类型。
The delivery service provided by FCAST might be fully reliable, or only partially reliable, depending upon:
FCAST提供的交付服务可能完全可靠，也可能仅部分可靠，具体取决于：
o the way ALC or NORM is used (e.g., whether FEC encoding and/or NACK-based repair requests are used or not),
o 使用ALC或NORM的方式（例如，是否使用FEC编码和/或基于NACK的修复请求），
o the way the FCAST carousel is used (e.g., whether the objects are made available for a long time span or not), and
o FCAST旋转木马的使用方式（例如，对象是否可供长时间使用），以及
o the way in which FCAST itself is deployed (e.g., whether there is a session control application that might automatically extend an existing FCAST session until all receivers have received the transmitted content).
o FCAST本身的部署方式（例如，是否有会话控制应用程序可以自动扩展现有FCAST会话，直到所有接收器都接收到传输的内容）。
The receiver set can be restricted to a single receiver or possibly a very large number of receivers. While the choice of the underlying transport protocol (i.e., ALC or NORM) and its parameters may limit the practical receiver group size, nothing in FCAST itself limits it. For instance, if FCAST/ALC is used on top of purely unidirectional transport channels with no feedback information at all, which is the default mode of operation, then scalability is at a maximum, since neither FCAST, ALC, UDP, nor IP generates any feedback message. On the contrary, the scalability of FCAST/NORM is typically limited by the scalability of NORM itself. For example, NORM can be configured to operate using proactive FEC without feedback, similar to ALC, with receivers configured to provide NACK and, optionally, ACK feedback,
接收机集可以限制为单个接收机，也可以限制为非常多的接收机。虽然底层传输协议（即ALC或NORM）及其参数的选择可能会限制实际的接收器组大小，但FCAST本身没有任何限制。例如，如果FCAST/ALC用于完全没有反馈信息的单向传输信道之上，这是默认的操作模式，那么可伸缩性将达到最大值，因为FCAST、ALC、UDP和IP都不会生成任何反馈消息。相反，FCAST/NORM的可伸缩性通常受到NORM本身可伸缩性的限制。例如，NORM可配置为使用无反馈的主动FEC进行操作，类似于ALC，接收机配置为提供NACK和（可选）ACK反馈，
or a hybrid combination of these. Similarly, if FCAST is used along with a session control application that collects reception information from the receivers, then this session control application may limit the scalability of the global object delivery system. This situation can of course be mitigated by using a hierarchy of servers or feedback message aggregation. The details of this are out of the scope of the present document.
或者这些的混合组合。类似地，如果FCAST与从接收机收集接收信息的会话控制应用程序一起使用，则该会话控制应用程序可能限制全局对象交付系统的可伸缩性。当然，可以通过使用服务器层次结构或反馈消息聚合来缓解这种情况。这方面的细节超出了本文件的范围。
The content of a Carousel Instance MAY be described by means of an OPTIONAL CID (Section 3.5). The decision of whether the CID mechanism should be used or not is left to the sender. When it is used, the question of how often and when a CID should be sent is also left to the sender. These considerations depend on many parameters, including the target use-case and the session dynamics. For instance, it may be appropriate to send a CID at the beginning of each new Carousel Instance and then periodically. These operational aspects are out of the scope of the present document.
转盘实例的内容可通过可选CID进行描述（第3.5节）。是否应使用CID机制的决定权留给发送方。当使用CID时，发送CID的频率和时间也留给发送方。这些考虑因素取决于许多参数，包括目标用例和会话动态。例如，在每个新的转盘实例开始时发送CID，然后定期发送可能是合适的。这些业务方面超出了本文件的范围。
Per this specification, IANA has created three new registries.
根据该规范，IANA创建了三个新的注册表。
IANA has created a new registry, "FCAST Object Metadata Format" (MDFmt), with a reference to this document. The registry entries consist of a numeric value from 0 to 15, inclusive (i.e., they are 4-bit positive integers), that defines the format of the object metadata (see Section 2.1).
IANA已经创建了一个新的注册表“FCAST对象元数据格式”（MDFmt），并引用了本文档。注册表项由0到15（包括）的数值组成（即，它们是4位正整数），定义了对象元数据的格式（参见第2.1节）。
The initial value for this registry is defined below. Future assignments are to be made through Expert Review with Specification Required [RFC5226].
此注册表的初始值定义如下。未来的任务将通过专家评审完成，并符合规范要求[RFC5226]。
+-------------+---------------------+--------------+----------------+
| Value | Format Name | Format | Reference |
| | | Reference | |
+-------------+---------------------+--------------+----------------+
| 0 (default) | HTTP/1.1 | [RFC2616], | This |
| | metainformation | Section 7.1 | specification |
| | format | | |
+-------------+---------------------+--------------+----------------+
+-------------+---------------------+--------------+----------------+
| Value | Format Name | Format | Reference |
| | | Reference | |
+-------------+---------------------+--------------+----------------+
| 0 (default) | HTTP/1.1 | [RFC2616], | This |
| | metainformation | Section 7.1 | specification |
| | format | | |
+-------------+---------------------+--------------+----------------+
IANA has created a new registry, "FCAST Object Metadata Encoding" (MDEnc), with a reference to this document. The registry entries consist of a numeric value from 0 to 15, inclusive (i.e., they are 4-bit positive integers), that defines the encoding of the Object Metadata field (see Section 2.1).
IANA已经创建了一个新的注册表“FCAST对象元数据编码”（MDEnc），并引用了本文档。注册表项由0到15（包括）的数值组成（即，它们是4位正整数），用于定义对象元数据字段的编码（参见第2.1节）。
The initial values for this registry are defined below. Future assignments are to be made through Expert Review [RFC5226].
此注册表的初始值定义如下。未来的任务将通过专家评审[RFC5226]完成。
+---------+------------------+-----------------+--------------------+
| Value | Encoding Name | Encoding | Reference |
| | | Reference | |
+---------+------------------+-----------------+--------------------+
| 0 | UTF-8 encoded | [RFC3629] | This specification |
| | text | | |
| | | | |
| 1 | GZIP'ed UTF-8 | [RFC1952], | This specification |
| | encoded text | [RFC3629] | |
+---------+------------------+-----------------+--------------------+
+---------+------------------+-----------------+--------------------+
| Value | Encoding Name | Encoding | Reference |
| | | Reference | |
+---------+------------------+-----------------+--------------------+
| 0 | UTF-8 encoded | [RFC3629] | This specification |
| | text | | |
| | | | |
| 1 | GZIP'ed UTF-8 | [RFC1952], | This specification |
| | encoded text | [RFC3629] | |
+---------+------------------+-----------------+--------------------+
IANA has created a new registry, "FCAST Object Metadata Types" (MDType), with a reference to this document. The registry entries consist of additional text metadata type identifiers and descriptions for metadata item types that are specific to FCAST operation and not previously defined in [RFC2616]. The initial values are those described in Section 3.3 of this specification. This table summarizes those initial registry entries. Future assignments are to be made through Expert Review [RFC5226].
IANA创建了一个新的注册表“FCAST对象元数据类型”（MDType），并引用了本文档。注册表项由附加的文本元数据类型标识符和元数据项类型的描述组成，这些元数据项类型特定于FCAST操作，并且以前未在[RFC2616]中定义。初始值如本规范第3.3节所述。此表汇总了这些初始注册表项。未来的任务将通过专家评审[RFC5226]完成。
+-------------------------+-----------------------+-----------------+
| Metadata Type | Description | Reference |
+-------------------------+-----------------------+-----------------+
| Fcast-Obj-Digest-SHA1 | A string that | This |
| | contains the "base64" | specification |
| | encoding of the SHA-1 | |
| | message digest of the | |
| | object before any | |
| | content encoding is | |
| | applied (if any) and | |
| | without considering | |
| | the FCAST Header | |
| | | |
| Fcast-Obj-Digest-SHA256 | A string that | This |
| | contains the "base64" | specification |
| | encoding of the | |
| | SHA-256 message | |
| | digest of the object | |
| | before any content | |
| | encoding is applied | |
| | (if any) and without | |
| | considering the FCAST | |
| | Header | |
| | | |
| Fcast-Obj-Slice-Nb | Unsigned 32-bit | This |
| | integer that contains | specification |
| | the total number of | |
| | slices. A value | |
| | greater than 1 | |
| | indicates that this | |
| | object is the result | |
| | of a split of the | |
| | original object | |
| | | |
| Fcast-Obj-Slice-Idx | Unsigned 32-bit | This |
| | integer that contains | specification |
| | the slice index (in | |
| | the {0 .. SliceNb - | |
| | 1} interval) | |
| | | |
| Fcast-Obj-Slice-Offset | Unsigned 64-bit | This |
| | integer that contains | specification |
| | the byte offset at | |
| | which this slice | |
| | starts within the | |
| | original object | |
+-------------------------+-----------------------+-----------------+
+-------------------------+-----------------------+-----------------+
| Metadata Type | Description | Reference |
+-------------------------+-----------------------+-----------------+
| Fcast-Obj-Digest-SHA1 | A string that | This |
| | contains the "base64" | specification |
| | encoding of the SHA-1 | |
| | message digest of the | |
| | object before any | |
| | content encoding is | |
| | applied (if any) and | |
| | without considering | |
| | the FCAST Header | |
| | | |
| Fcast-Obj-Digest-SHA256 | A string that | This |
| | contains the "base64" | specification |
| | encoding of the | |
| | SHA-256 message | |
| | digest of the object | |
| | before any content | |
| | encoding is applied | |
| | (if any) and without | |
| | considering the FCAST | |
| | Header | |
| | | |
| Fcast-Obj-Slice-Nb | Unsigned 32-bit | This |
| | integer that contains | specification |
| | the total number of | |
| | slices. A value | |
| | greater than 1 | |
| | indicates that this | |
| | object is the result | |
| | of a split of the | |
| | original object | |
| | | |
| Fcast-Obj-Slice-Idx | Unsigned 32-bit | This |
| | integer that contains | specification |
| | the slice index (in | |
| | the {0 .. SliceNb - | |
| | 1} interval) | |
| | | |
| Fcast-Obj-Slice-Offset | Unsigned 64-bit | This |
| | integer that contains | specification |
| | the byte offset at | |
| | which this slice | |
| | starts within the | |
| | original object | |
+-------------------------+-----------------------+-----------------+
The authors are grateful to the authors of [ALC-00] for specifying the first version of FCAST/ALC. The authors are also grateful to David Harrington, Gorry Fairhurst, and Lorenzo Vicisano for their valuable comments. The authors are also grateful to Jari Arkko, Ralph Droms, Wesley Eddy, Roni Even, Stephen Farrell, Russ Housley, Chris Lonvick, Pete Resnick, Joseph Yee, and Martin Stiemerling.
作者感谢[ALC-00]的作者指定了FCAST/ALC的第一个版本。作者还感谢David Harrington、Gorry Fairhurst和Lorenzo Vicisano的宝贵评论。作者还感谢贾里·阿尔科、拉尔夫·德罗姆斯、韦斯利·艾迪、罗尼·埃文、斯蒂芬·法雷尔、罗斯·霍斯利、克里斯·朗维克、皮特·雷斯尼克、约瑟夫·叶和马丁·斯蒂梅林。
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC1071]Braden，R.，Borman，D.，Partridge，C.，和W.Plummer，“计算互联网校验和”，RFC 10711988年9月。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[RFC1952]Deutsch，P.，“GZIP文件格式规范版本4.3”，RFC1952，1996年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[RFC3174]Eastlake，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 3174，2001年9月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, October 2009.
[RFC5651]Luby，M.，Watson，M.，和L.Vicisano，“分层编码传输（LCT）构建块”，RFC 5651，2009年10月。
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009.
[RFC5740]Adamson，B.，Bormann，C.，Handley，M.，和J.Macker，“面向NACK的可靠多播（NORM）传输协议”，RFC 57402009年11月。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, April 2010.
[RFC5775]Luby，M.，Watson，M.，和L.Vicisano，“异步分层编码（ALC）协议实例化”，RFC 5775，2010年4月。
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6234]Eastlake，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，2011年5月。
[ALC-00] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Crowcroft, J., and B. Lueckenhoff, "Asynchronous Layered Coding: A scalable reliable multicast protocol", Work in Progress, March 2000.
[ALC-00]Luby，M.，Gemmell，J.，Vicisano，L.，Rizzo，L.，Crowcroft，J.，和B.Lueckenhoff，“异步分层编码：一种可扩展的可靠多播协议”，正在进行的工作，2000年3月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104]Krawczyk，H.，Bellare，M.，和R.Canetti，“HMAC：用于消息认证的键控哈希”，RFC 2104，1997年2月。
[RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", BCP 61, RFC 3365, August 2002.
[RFC3365]Schiller，J.“互联网工程任务组标准协议的强大安全要求”，BCP 61，RFC 3365，2002年8月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005.
[RFC4082]Perrig，A.，Song，D.，Canetti，R.，Tygar，J.，和B.Briscoe，“定时高效流丢失容忍认证（TESLA）：多播源认证转换介绍”，RFC 40822005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, August 2007.
[RFC5052]Watson，M.，Luby，M.，和L.Vicisano，“前向纠错（FEC）构建块”，RFC 5052，2007年8月。
[RFC5510] Lacan, J., Roca, V., Peltotalo, J., and S. Peltotalo, "Reed-Solomon Forward Error Correction (FEC) Schemes", RFC 5510, April 2009.
[RFC5510]Lacan，J.，Roca，V.，Peltotalo，J.，和S.Peltotalo，“里德-所罗门前向纠错（FEC）方案”，RFC 55102009年4月。
[RFC5776] Roca, V., Francillon, A., and S. Faurite, "Use of Timed Efficient Stream Loss-Tolerant Authentication (TESLA) in the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 5776, April 2010.
[RFC5776]Roca，V.，Francillon，A.，和S.Faurite，“在异步分层编码（ALC）和面向NACK的可靠多播（NORM）协议中使用定时高效流丢失容忍认证（TESLA）”，RFC 5776，2010年4月。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, October 2011.
[RFC6363]Watson，M.，Begen，A.，和V.Roca，“前向纠错（FEC）框架”，RFC6363，2011年10月。
[RFC6584] Roca, V., "Simple Authentication Schemes for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6584, April 2012.
[RFC6584]Roca，V.“异步分层编码（ALC）和面向NACK的可靠多播（NORM）协议的简单认证方案”，RFC 6584，2012年4月。
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, November 2012.
[RFC6726]Paila，T.，Walsh，R.，Luby，M.，Roca，V.，和R.Lehtonen，“长笛-单向传输上的文件交付”，RFC 6726，2012年11月。
[RMT-SEC] Adamson, B., Roca, V., and H. Asaeda, "Security and Reliable Multicast Transport Protocols: Discussions and Guidelines", Work in Progress, May 2013.
[RMT-SEC]Adamson，B.，Roca，V.，和H.Asaeda，“安全和可靠多播传输协议：讨论和指南”，正在进行的工作，2013年5月。
This appendix provides informative examples of FCAST Compound Objects and Carousel Instance Descriptor formats.
本附录提供了FCAST复合对象和旋转木马实例描述符格式的信息示例。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver=0| 0 |1|0|MDFmt=0|MDEnc=0| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCAST Header Length=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. "Content-Location: example_1.txt<CR-LF>" metadata (33 bytes) .
. .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Object Data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver=0| 0 |1|0|MDFmt=0|MDEnc=0| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCAST Header Length=41 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. "Content-Location: example_1.txt<CR-LF>" metadata (33 bytes) .
. .
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Object Data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Simple Compound Object Example
图4：简单的复合对象示例
Figure 4 shows a simple Compound Object where the metadata string, in HTTP/1.1 metainformation format (MDFmt=0), contains:
图4显示了一个简单的复合对象，其中HTTP/1.1元信息格式（MDFmt=0）的元数据字符串包含：
Content-Location: example_1.txt<CR-LF>
Content-Location: example_1.txt<CR-LF>
This UTF-8 encoded text (since MDEnc=0) is 33 bytes long (there is no final '\0' character). Therefore, 3 padding bytes are added. There is no Content-Length metadata entry for the object transported (without FCAST additional encoding) in the Object Data field, since this length can easily be calculated by the receiver as the FEC OTI Transfer Length minus the header length. Finally, the checksum encompasses the whole Compound Object (G=1).
此UTF-8编码文本（因为MDEnc=0）的长度为33字节（没有最后的“\0”字符）。因此，添加了3个填充字节。对象数据字段中没有传输对象的内容长度元数据条目（无FCAST附加编码），因为接收方可以轻松地将该长度计算为FEC OTI传输长度减去报头长度。最后，校验和包含整个复合对象（G=1）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver=0| 0 |1|1|MDFmt=0|MDEnc=0| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCAST Header Length=31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. "Fcast-CID-Complete: 1<CR-LF>" metadata string (23 bytes) .
. .
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Object List string .
. .
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver=0| 0 |1|1|MDFmt=0|MDEnc=0| Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCAST Header Length=31 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. "Fcast-CID-Complete: 1<CR-LF>" metadata string (23 bytes) .
. .
+ +-+-+-+-+-+-+-+-+
| | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. .
. Object List string .
. .
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+
Figure 5: CID Object Example: Static Session
图5:CID对象示例：静态会话
Figure 5 shows an example CID object, in the case of a static FCAST session, i.e., a session where the set of objects is set once and for all. The metadata UTF-8 encoded text only contains the following entry, since Fcast-CID-ID is implicit:
图5显示了静态FCAST会话中的示例CID对象，即对象集一次性设置的会话。元数据UTF-8编码文本仅包含以下条目，因为Fcast CID ID是隐式的：
Fcast-CID-Complete: 1<CR-LF>
Fcast-CID-Complete: 1<CR-LF>
This UTF-8 encoded text (since MDEnc=0) is 23 bytes long (there is no final '\0' character). Therefore, 1 padding byte is added.
此UTF-8编码文本（因为MDEnc=0）的长度为23字节（没有最后的“\0”字符）。因此，添加1个填充字节。
The Object List contains the following 25-byte-long string (there is no final '\0' character):
对象列表包含以下25字节长的字符串（没有最后的“\0”字符）：
1,2,3,100-104,200-203,299
1,2,3,100-104,200-203,299
There are therefore a total of 3+5+4+1 = 13 objects in the Carousel Instance and therefore in the FCAST session. There is no metadata associated to this CID. As the session is static and composed of a single Carousel Instance, the sender did not feel the necessity to carry a Carousel Instance ID metadata.
因此，旋转木马实例和FCAST会话中总共有3+5+4+1=13个对象。没有与此CID关联的元数据。由于会话是静态的，并且由单个旋转木马实例组成，发送方认为没有必要携带旋转木马实例ID元数据。
In certain use-cases, FCAST can take advantage of another in-band (e.g., via NORM_INFO messages (Appendix B.2)) or out-of-band signaling mechanism. This section provides an overview of how other signaling mechanisms could be employed and a normative specification for how FCAST information is embedded when NORM_INFO messages are used for carrying FCAST Headers. Such additional signaling schemes can be used to carry the whole metadata, or a subset of it, ahead of time, before the associated Compound Object. Therefore, based on the information retrieved in this way, a receiver could decide in advance (i.e., before beginning the reception of the compound object) whether the object is of interest or not; this would mitigate the limitations of FCAST. While out-of-band techniques are out of the scope of this document, we explain below how this can be achieved in the case of FCAST/NORM.
在某些用例中，FCAST可以利用另一种带内（例如，通过NORM_信息消息（附录B.2））或带外信令机制。本节概述了如何使用其他信令机制，以及在使用NORM_INFO消息承载FCAST报头时如何嵌入FCAST信息的规范性规范。此类附加信令方案可用于在相关联的复合对象之前提前携带整个元数据或其子集。因此，基于以这种方式检索的信息，接收器可以提前（即，在开始接收复合对象之前）确定对象是否感兴趣；这将减轻FCAST的限制。虽然带外技术不在本文档的范围内，但我们将在下面解释如何在FCAST/NORM的情况下实现这一点。
Supporting additional mechanisms is OPTIONAL in FCAST implementations. In any case, an FCAST sender MUST continue to send all the required metadata in the Compound Object, even if the whole metadata, or a subset of it, is sent by another mechanism (Section 4). Additionally, when metadata is sent several times, there MUST NOT be any contradiction in the information provided by the different mechanisms. If a mismatch is detected, the metadata contained in the Compound Object MUST be used as the definitive source.
在FCAST实现中，支持其他机制是可选的。在任何情况下，FCAST发送方必须继续发送复合对象中所有必需的元数据，即使整个元数据或其子集是由另一种机制发送的（第4节）。此外，在多次发送元数据时，不同机制提供的信息中不得存在任何矛盾。如果检测到不匹配，则复合对象中包含的元数据必须用作最终源。
When metadata elements are communicated out-of-band, in advance of data transmission, the following piece of information can be useful:
当元数据元素在数据传输之前进行带外通信时，以下信息可能很有用：
o TOI: a positive integer that contains the Transport Object Identifier (TOI) of the object, in order to enable a receiver to easily associate the metadata to the object. The valid range for TOI values is discussed in Section 3.6.
o TOI：一个正整数，包含对象的传输对象标识符（TOI），以便接收方能够轻松地将元数据与对象关联。第3.6节讨论了TOI值的有效范围。
The NORM_INFO message of NORM can convey "out-of-band" content with respect to a given transport object. With FCAST, this message MAY be used as an additional mechanism to transmit metadata. In that case, the NORM_INFO message carries a new Compound Object that contains all the metadata of the original object, or a subset of it. The NORM_INFO Compound Object MUST NOT contain any Object Data field (i.e., it is only composed of the header), it MUST feature a non-global checksum, and it MUST NOT include a Padding field. Finally, note that the availability of NORM_INFO for a given object is signaled through the use of a dedicated flag in the NORM_DATA message header. Along with NORM's NACK-based repair request signaling, it allows a receiver to quickly (and independently) request an object's NORM_INFO content. However, a limitation here is that the FCAST Header MUST fit within the byte size limit defined by the NORM sender's configured "segment size" (typically a little less than the network MTU).
NORM的NORM_INFO消息可以传送关于给定传输对象的“带外”内容。对于FCAST，此消息可用作传输元数据的附加机制。在这种情况下，NORM_INFO消息携带一个新的复合对象，该对象包含原始对象的所有元数据或其子集。NORM_INFO复合对象不得包含任何对象数据字段（即，它仅由标题组成），必须具有非全局校验和，并且不得包含填充字段。最后，请注意，给定对象的NORM_信息的可用性是通过在NORM_数据消息头中使用专用标志来表示的。与NORM基于NACK的修复请求信令一起，它允许接收器快速（独立）请求对象的NORM_信息内容。然而，这里的一个限制是FCAST头必须符合NORM发送方配置的“段大小”（通常略小于网络MTU）定义的字节大小限制。
In the case of FCAST/NORM, the object metadata (or a subset of it) can be carried as part of a NORM_INFO message, as a new Compound Object that does not contain any Object Data. In the following informative example, we assume that the whole metadata is carried in such a message. Figure 6 shows an example NORM_INFO message that contains the FCAST Header, including metadata. In this example, the first 16 bytes are the NORM_INFO base header; the next 12 bytes are a NORM EXT_FTI header extension containing the FEC Object Transport Information for the associated object; and the remaining bytes are the FCAST Header, including metadata. Note that "padding" MUST NOT be used and that the FCAST checksum only encompasses the Compound Object Header (G=0).
对于FCAST/NORM，对象元数据（或其子集）可以作为NORM_INFO消息的一部分携带，作为不包含任何对象数据的新复合对象。在下面的示例中，我们假设整个元数据都包含在这样的消息中。图6显示了一个示例NORM_INFO消息，其中包含FCAST头，包括元数据。在本例中，前16个字节是NORM_INFO base头；接下来的12个字节是包含相关对象的FEC对象传输信息的NORM extu FTI报头扩展；剩下的字节是FCAST头，包括元数据。请注意，不得使用“填充”，并且FCAST校验和仅包含复合对象标题（G=0）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --
|version| type=1| hdr_len = 7 | sequence | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| source_id | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o
| instance_id | grtt |backoff| gsize | r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ m
| flags | fec_id = 5 | object_transport_id | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --
| HET = 64 | HEL = 3 | | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + f
| Transfer Length = 41 | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i
| Encoding Symbol Length (E) | MaxBlkLen (B) | max_n | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --
| 0 | 0 |0|0| 0 | 0 | Checksum | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 41 | f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| c
. . a
. metadata UTF-8 encoded text (32 bytes) . s
. . t
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | v
+-+-+-+-+-+-+-+-+ --
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --
|version| type=1| hdr_len = 7 | sequence | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| source_id | n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o
| instance_id | grtt |backoff| gsize | r
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ m
| flags | fec_id = 5 | object_transport_id | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --
| HET = 64 | HEL = 3 | | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + f
| Transfer Length = 41 | t
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ i
| Encoding Symbol Length (E) | MaxBlkLen (B) | max_n | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --
| 0 | 0 |0|0| 0 | 0 | Checksum | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| 41 | f
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| c
. . a
. metadata UTF-8 encoded text (32 bytes) . s
. . t
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | v
+-+-+-+-+-+-+-+-+ --
Figure 6: NORM_INFO Message Containing an EXT_FTI Header Extension and an FCAST Header
图6:NORM_INFO消息包含EXT_FTI头扩展和FCAST头
The NORM_INFO message shown in Figure 6 contains the EXT_FTI header extension to carry the FEC OTI. In this example, the FEC OTI format is that of the Reed-Solomon FEC coding scheme for fec_id = 5, as described in [RFC5510]. Other alternatives for providing the FEC OTI would have been to either include it directly in the metadata of the FCAST Header or to include an EXT_FTI header extension to all NORM_DATA packets (or a subset of them). Note that the NORM "Transfer Length" is the total length of the associated Compound Object, i.e., 41 bytes.
图6所示的NORM_INFO消息包含EXT_FTI头扩展，以承载FEC OTI。在该示例中，FEC OTI格式是FEC_id＝5的里德-所罗门FEC编码方案的格式，如[RFC5510]中所述。提供FEC-OTI的其他备选方案是直接将其包括在FCAST报头的元数据中，或者将EXT_-FTI报头扩展包括到所有NORM_数据包（或其子集）。请注意，规范“传输长度”是关联复合对象的总长度，即41字节。
The Compound Object in this example does contain the same metadata and is formatted as in the example of Figure 4. With the combination of the FEC_OTI and the FCAST metadata, the NORM protocol and FCAST application have all of the information needed to reliably receive and process the associated object. Indeed, the NORM protocol provides rapid (NORM_INFO has precedence over the associated object content), reliable delivery of the NORM_INFO message and its payload, the FCAST Compound Object.
本例中的复合对象包含相同的元数据，其格式如图4所示。通过FEC_OTI和FCAST元数据的组合，NORM协议和FCAST应用程序拥有可靠接收和处理关联对象所需的所有信息。事实上，NORM协议提供了快速（NORM_INFO优先于相关对象内容）、可靠的NORM_INFO消息及其有效负载FCAST复合对象的传递。
Authors' Addresses
作者地址
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
Vincent Roca INRIA 655，av。欧洲伊诺瓦利；蒙博诺圣伊斯梅尔塞德斯38334法国
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/
Brian Adamson Naval Research Laboratory Washington, DC 20375 USA
布莱恩·亚当森海军研究实验室，华盛顿特区，美国20375
EMail: adamson@itd.nrl.navy.mil
URI: http://cs.itd.nrl.navy.mil
EMail: adamson@itd.nrl.navy.mil
URI: http://cs.itd.nrl.navy.mil