[要約] RFC 6968は、ALCとNORMプロトコルのためのオブジェクト配信を扱っています。このRFCの目的は、ALCとNORMプロトコルの効率的なオブジェクト配信を実現するためのFCASTプロトコルを提案することです。
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：Asynchronous Layered Coding（ALC）およびNACK-Oriented Reliable Multicast（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.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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には2つのバリアントがあります。
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自体は新しいプロトコル仕様ではありません。代わりに、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とは異なります。これについては、セクション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もレシーバーの数を制限しないため、当然のことながら大規模にスケーラブルです（フィードバックメッセージはまったくありません）。逆に、NORMはレシーバーからのフィードバックメッセージに依存するため、FCAST / 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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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ヘッダー：複合オブジェクトを形成するオブジェクトデータの前に付加されるヘッダーを示します。この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.
カルーセルインスタンスID（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.
カルーセルサイクル：カルーセルインスタンスに登録されているすべての複合オブジェクトが特定の回数送信される送信ラウンドを示します。デフォルトでは、複合オブジェクトはサイクルごとに1回送信されますが、オブジェクトごとに異なる可能性のある、より高い値も可能です。
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) .
. .
. .
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. |
| | |
| 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.
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
Figure 2: Carousel Instance Descriptor Format
図2：カルーセルインスタンス記述子の形式
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-Complete：1」に設定すると、このCIDにTOIがリストされているオブジェクトに加えて、新しいオブジェクトがないことを示します（CID複合オブジェクトを無視した場合）。または、以前のCIDに記載されているものは、今後送信されます。逆に、「Fcast-CID-Complete：0」に設定されている場合、またはこのエントリがない場合は、セッションが完了していないことを示しています。 FCAST送信者は、このエントリに他の値を使用してはなりません（MUST NOT）。
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：このエントリには、カルーセルインスタンスIDentifier、または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 Content-Length：コンテンツエンコーディング（存在する場合）の前の、オブジェクトリストのサイズをバイト単位で指定します。
o Content-Encoding: specifies the optional encoding of the Object List, performed by FCAST.
o Content-Encoding：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の場合、必ずしもNULLで終了するとは限らないUTF-8エンコードされたテキストです。次の2つを含めることができます。
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 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のリストは、カンマ区切りの個々のTOI値またはTOI間隔、あるいはその両方を含むASCII文字列として指定されます。個々のTOIは単一の整数値で構成されますが、TOI間隔はハイフンで区切られたTOI値のペアで、TOI値の包括的な範囲を示します（たとえば、 "1,2,4-6"は1のTOI値のリストを示します） 、2、4、5、6）。 「TOI_a-TOI_b」で示されるTOI間隔の場合、「TOI_a」の値は「TOI_b」の値よりも厳密に低くなければなりません。間隔内で0へのTOIラッピングが発生する場合、TOI_a-MAX_TOIおよび0-TOI_bの2つのTOI間隔を指定する必要があります。
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プロトコルの場合、NACKベースのプロトコル操作のためにNormTransportId値を単調に増加させる必要があります。これにより、前のカルーセルインスタンスからのオブジェクトを後続のカルーセルインスタンスに再リストして、レシーバーセットに同等性が通知されるため、不要になります。再送信要求を回避できます。
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
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等価要素は、新しいTOI順序の昇順でリストの最後にグループ化する必要があります。特定のnewTOIにTOIと同等のものを指定すると、TOIリストでnewTOIを明示的に指定する必要がなくなります。受信者は、TOI値とTOI等価リストの両方に同じTOIが現れる状況を処理できなければなりません（MUST）。最後に、所定の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)
or equivalently:
または同等：
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は2つの操作形式をサポートします。
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) |
+-------------------------+--------------------------------------+
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 Content-Location：オブジェクトのURI。オブジェクトの名前と場所を示します。
o Content-Type: a string that contains the MIME type of the object.
o Content-Type：オブジェクトの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 Content-Length：コンテンツエンコード（存在する場合）の前に、FCASTヘッダーを考慮せずに、初期オブジェクトのバイト単位のサイズを含む符号なし64ビット整数。特定のFECスキームを使用すると、オブジェクトの最大値がさらに制限される場合があります。
o Content-Encoding: a string that contains the optional encoding of the object performed by FCAST. For instance:
o Content-Encoding：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]でエンコードされていることを示します。 Content-Encodingエントリがない場合、受信者は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：オブジェクトのSHA-256メッセージダイジェストの[base64] [RFC4648]エンコードを含む文字列[RFC3174] [RFC6234]。 FCASTヘッダー。このダイジェストは、インテリジェントな攻撃者による意図的な攻撃（セクション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：（{0 .. SliceNb-1}間隔で）スライスインデックスを含む符号なし32ビット整数。
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-Slice-Offset：元のオブジェクト内でこのスライスが開始するオフセットを含む符号なし64ビット整数。
Future IANA assignments to extend the set of metadata types supported by FCAST are to be made through Expert Review [RFC5226].
FCASTによってサポートされる一連のメタデータタイプを拡張するための将来のIANA割り当ては、Expert Review [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).
特定のカルーセルインスタンスでは、1つ以上の送信サイクルが可能です。各サイクル中に、カルーセルを構成するすべての複合オブジェクトが送信されます。デフォルトでは、各オブジェクトはサイクルごとに1回送信されます。ただし、異なるレベルの優先度を許可するために、一部のオブジェクトは、サイクル中に他のオブジェクトよりも頻繁に送信されたり、他のオブジェクトよりも高い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送信側は、OPTIONAL 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 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).
この特別なオブジェクトはALC / LCTまたはNORMによって標準オブジェクトと見なされるため、CID複合オブジェクト自体には予約済みのTOI値はありません。逆に、このオブジェクト（CID）の性質は、特定のFCASTヘッダーフィールド（図1の「C」フラグ）によって示されるため、必要に応じてFCASTアプリケーションで認識および処理できます。直接的な結果として、レシーバーは次のCIDに使用されるTOIを事前に知らないため（動的セッションの場合）、現在のCIDのTOIリストにないパケットを除外してはなりません（MUST NOT）。言い換えると、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」に設定された「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を使用してカルーセルからいくつかのオブジェクトが削除されたことを受信者に確実に通知できます。断続的な接続を持つクライアントは、この「B」フラグを含むすべてのパケットを失う可能性があるため、このソリューションはALC / LCTのオブジェクトの「B」クローズフラグよりも堅牢です。そして、NORMは、受信者のNACK修復要求に応答して、NORM_CMD（SQUELCH）メッセージの形式で堅牢なオブジェクトキャンセルメカニズムを提供しますが、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プロトコルが提供するオブジェクトベースのトランスポートサービスに直接関連付けられています。各プロトコルでは、トランスポートオブジェクトコンテンツを含むパケットに、数値のトランスポートオブジェクト識別子（TOCと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 TOIフィールドは16ビット長であり、TOIは順次管理する必要があるため、NORMによる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.
* ユーザーが1つまたは複数の新しいオブジェクトをカルーセルに追加したい、または逆に古いオブジェクトをカルーセルから削除したい。その場合、新しいカルーセルインスタンスを作成する必要があります。
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. FCASTヘッダーに設定された「C」フラグで示されるように、CIDが受信されると、レシーバーは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. |
+------------------+------------------------------------------------+
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. |
+-----------------+-------------------------------------------------+
Metadata items (Section 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. |
+-------------------------------+-----------------------------------+
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. |
+--------------------+--------------------+
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.
最新の暗号化メカニズムは、送信されたオブジェクトへのアクセス制御を提供できます。これを行う1つの方法は、送信前にオブジェクト全体を暗号化し、認証された受信者がコンテンツを復号化する暗号化メカニズムを備えていることを確認することです。別の方法は、IPsec / ESP [RFC4303]を使用して個々のパケットを暗号化することです（セクション5.5も参照）。これらの2つの手法は、転送されるオブジェクトに機密性を提供することもできます。
If access control and/or confidentiality services are desired, one of these mechanisms is RECOMMENDED and SHOULD be deployed.
アクセス制御や機密性サービスが必要な場合は、これらのメカニズムの1つを推奨し、展開する必要があります。
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]を使用して、オブジェクトにデジタル署名を付けることができます。このシグネチャにより、受信者はオブジェクトの整合性をチェックできます。デジタル署名の計算コストが高い場合でも、この計算はオブジェクトごとに1回だけ行われ、通常は許容されます。
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 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パケットレベルで、グループキーメッセージ認証コード（MAC）[RFC2104] [RFC6584]スキームを使用できます。たとえば、HMAC-SHA-256を使用して、すべてのグループメンバー、送信者、そしてレシーバー。この手法は、パケット自体と一緒に送信される、パケットの暗号で保護されたダイジェストを作成します。 Group-keyed MACスキームは、法外な処理負荷や送信オーバーヘッドを作成しませんが、大きな制限があります。すべてのグループメンバーが同じ秘密グループキーを共有するため、グループ認証/整合性サービスのみを提供します。これは、各メンバーが偽造パケットを送信できることを意味します。したがって、グループメンバーが完全に信頼されている状況、または別の手法に関連して、非グループメンバーによって開始された攻撃を迅速に検出してパケットを破棄するための予備チェックとして制限されます。
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 パケットレベルでは、Timed Efficient Stream Loss-Tolerant Authentication（TESLA）[RFC4082] [RFC5776]は、損失に強い魅力的なソリューションであり、認証と整合性検証サービスを提供し、過度の処理負荷や送信オーバーヘッドを発生させません。 。ただし、TESLA認証パケットのチェックには遅延が発生します。この遅延は、いくつかのユースケースで望まれるものよりも大きい場合があります。
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.
公開鍵暗号化に依存する手法（ブートストラッププロセス中のデジタル署名とTESLAを使用する場合）では、公開鍵をエンティティに安全に関連付ける必要があります。これは、公開キー基盤（PKI）、プリティグッドプライバシー（PGP）Web of Trustを介して、または各グループメンバーの公開キーを安全に置き換えることによって実現できます。
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.
どのアプリケーションが最も適切であるかを定義するのは、ターゲットアプリケーション領域のセキュリティ要件と機能を知っている開発者とデプロイヤー次第です。いずれの場合でも、オブジェクトが破損する恐れがある場合は、これらの手法の少なくとも1つを使用することをお勧めします。セクション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 the ALC/LCT parameters, carried within the LCT header, or
oオブジェクトのメタデータ、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.
これらの問題を回避するには、受信者が誤ったセッション記述を受け入れないようにするための対策を講じることをお勧めします。そのような手段の1つは、受信者が承認された送信者からの正当なセッション記述のみを受け入れることを保証する送信者認証です。このセッションの説明は通常、帯域外で行われるため、これらの手段がどのように達成されるかは、このドキュメントの範囲外です。
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攻撃を作成する1つの方法です。たとえば、攻撃者は「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の送信者のIDをチェックするための対策を講じることをお勧めします。そのためには、上記の対策（セクション5.2.2）の1つを使用する必要があります。これらの対策は、パケットレベルで適用されるか、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.
オブジェクトメタデータの変更は、攻撃を開始するもう1つの方法です。たとえば、攻撃者はオブジェクトに関連付けられたメッセージダイジェストを変更し、正しく受信された場合でも、受信者がオブジェクトを拒否するようにします。より一般的には、受信者はメタデータの処理中に非常に注意する必要があります。たとえば、受信者はリンク（たとえば、Content-Locationメタデータに含まれるURI）をたどることを試みるべきではありません（SHOULD NOT）。別の例として、不正な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）の1つを使用する必要があります。これらの測定値は、パケットレベルで適用されるか、複合オブジェクト全体にグローバルに適用されます。パケットレベルの整合性検証スキームがない場合は、複合オブジェクトにデジタル署名することをお勧めします。
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パケットを送信すると、レシーバーがセッションを途中で閉じる可能性があります。同様に、Close Object "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パケットで送信者のIDを確認するための対策を講じることをお勧めします。そのためには、上記の対策（セクション5.2.2）の1つを使用する必要があります。
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 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.
FCASTで輻輳制御を適用する場合は、セクション5.2.2で説明するように、パケットレベルの認証方式を使用することも推奨されます。 TESLAなどの一部のサービスでは遅延認証サービスしか提供されませんが、輻輳制御には迅速な対応が必要です。したがって、パケットがまだ認証されていない場合でも、輻輳が発生したと受信者が信じている場合、TESLAを使用する受信者はサブスクリプションレベルをすばやく下げることが推奨されます[RFC5775]。したがって、TESLAは、攻撃者が受信者に輻輳が発生したと信じ込ませる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操作」を継承しています。したがって、トランスポートモードのIPsec / ESPは、[RFC5775]および[RFC5740]に従って実装する必要がありますが、必ずしも使用する必要はありません。 [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の推奨ソリューションは、データ発信元認証、整合性検証、およびリプレイ防止機能を備えたパケット単位のセキュリティを提供します。これは、上記のインバンド攻撃のほとんどを防ぐのに十分です。機密性が必要な場合は、パケットごとの暗号化も使用する必要があります（SHOULD）。
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, 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.
レシーバーセットは、単一のレシーバーまたは非常に多数のレシーバーに制限できます。基盤となるトランスポートプロトコル（ALCまたはNORMなど）とそのパラメーターの選択により、実際の受信機グループのサイズが制限される場合がありますが、FCAST自体では制限されません。たとえば、FCAST / ALCが純粋な単方向のトランスポートチャネルの上で使用され、フィードバック情報がまったくない場合（デフォルトの動作モード）、FCAST、ALC、UDP、IPのいずれも生成しないため、スケーラビリティは最大になります。フィードバックメッセージ。逆に、FCAST / NORMのスケーラビリティは、通常、NORM自体のスケーラビリティによって制限されます。たとえば、NORMは、ALCと同様に、フィードバックなしのプロアクティブFECを使用して動作するように構成でき、レシーバーはNACKおよびオプションでACKフィードバック、またはこれらのハイブリッドの組み合わせを提供するように構成されます。同様に、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を送信するのが適切な場合があります。これらの運用面は、このドキュメントの範囲外です。
Per this specification, IANA has created three new registries.
この仕様に従って、IANAは3つの新しいレジストリを作成しました。
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 Object Metadata Format」（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 | | |
+-------------+---------------------+--------------+----------------+
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 Object Metadata Encoding」（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] | |
+---------+------------------+-----------------+--------------------+
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 | |
+-------------------------+-----------------------+-----------------+
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.
作成者は、FCAST / ALCの最初のバージョンを指定してくれた[ALC-00]の作成者に感謝しています。著者はまた、貴重なコメントをしてくれたDavid Harrington、Gorry Fairhurst、およびLorenzo Vicisanoにも感謝しています。著者は、Jari Arkko、Ralph Droms、Wesley Eddy、Roni Even、Stephen Farrell、Russ Housley、Chris Lonvick、Pete Resnick、Joseph Yee、Martin Stiemerlingにも感謝しています。
[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、「Computing the Internet checksum」、RFC 1071、1988年9月。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, May 1996.
[RFC1952] Deutsch、P。、「GZIPファイル形式仕様バージョン4.3」、RFC 1952、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-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、「US Secure Hash Algorithm 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。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、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、「RFCで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、「Layered Coding Transport（LCT）Building Block」、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-Oriented Reliable Multicast（NORM）Transport Protocol」、RFC 5740、2009年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、「Asynchronous Layered Coding（ALC）Protocol Instantiation」、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、「US Secure Hash Algorithms（SHA and SHA-based HMAC and 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、「非同期レイヤードコーディング：スケーラブルで信頼性の高いマルチキャストプロトコル」、Work in Progress 、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：Keyed-Hashing for Message Authentication」、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。、「Strong Security Requirements for Internet Engineering Task Force Standard Protocols」、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、「Public-Key Cryptography Standards（PKCS）＃1：RSA Cryptography Specifications Version 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、「Timed Efficient Stream Loss-Tolerant Authentication（TESLA）：Multicast Source Authentication Transform Introduction」、RFC 4082、 2005年6月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、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、「Forward Error Correction（FEC）Building Block」、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、「Reed-Solomon Forward Error Correction（FEC）Schemes」、RFC 5510、2009年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、「Asynchronous Layered Coding（ALC）およびNACK-Oriented Reliable Multicast（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、「Forward Error Correction（FEC）Framework」、RFC 6363、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、「FLUTE-単一方向トランスポートを介したファイル配信」、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、「セキュリティと信頼性の高いマルチキャストトランスポートプロトコル：ディスカッションとガイドライン」、Work in Progress、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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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>
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つのパディングバイトが追加されます。この長さは、FEC OTI転送長からヘッダー長を差し引いたものとして受信者が簡単に計算できるため、（FCAST追加エンコーディングなしで）トランスポートされたオブジェクトのContent-Lengthメタデータエントリはありません。最後に、チェックサムは複合オブジェクト全体を網羅します（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 .
. .
. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. |
+-+-+-+-+-+-+-+-+
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オブジェクトの例を示しています。 Fcast-CID-IDは暗黙的であるため、メタデータUTF-8エンコードテキストには次のエントリのみが含まれます。
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
１、２、３、１００ー１０４、２００ー２０３、２９９
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_INFOメッセージ（付録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）を含む正の整数。 TOI値の有効範囲については、セクション3.6で説明します。
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複合オブジェクトは、オブジェクトデータフィールド（つまり、ヘッダーのみで構成されている）を含んではならず（MUST）、非グローバルチェックサムを備えている必要があり、パディングフィールドを含んではいけません（MUST NOT）。最後に、特定のオブジェクトのNORM_INFOが利用可能であることは、NORM_DATAメッセージヘッダーの専用フラグを使用して通知されることに注意してください。 NORMのNACKベースの修復要求シグナリングに加えて、受信者はオブジェクトのNORM_INFOコンテンツをすばやく（独立して）要求できます。ただし、ここでの制限は、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は、メタデータを含むFCASTヘッダーを含むNORM_INFOメッセージの例を示しています。この例では、最初の16バイトはNORM_INFO基本ヘッダーです。次の12バイトは、関連付けられたオブジェクトのFECオブジェクトトランスポート情報を含むNORM EXT_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
+-+-+-+-+-+-+-+-+ --
Figure 6: NORM_INFO Message Containing an EXT_FTI Header Extension and an FCAST Header
図6：EXT_FTIヘッダー拡張とFCASTヘッダーを含むNORM_INFOメッセージ
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メッセージには、FEC OTIを伝送するためのEXT_FTIヘッダー拡張が含まれています。この例では、FEC OTIフォーマットは、[RFC5510]で説明されているように、fec_id = 5のリードソロモンFECコーディングスキームのフォーマットです。 FEC OTIを提供する他の代替手段は、FCASTヘッダーのメタデータに直接含めるか、すべてのNORM_DATAパケット（またはそれらのサブセット）に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メッセージとそのペイロードであるFCAST複合オブジェクトの迅速な（NORM_INFOが関連するオブジェクトコンテンツよりも優先されます）信頼性の高い配信を提供します。
Authors' Addresses
著者のアドレス
Vincent Roca INRIA 655, av. de l'Europe Inovallee; Montbonnot ST ISMIER cedex 38334 France
ヴィンセントロカINRIA 655、av。 Inovallee Europe; Montbonnot ST ISMIER cedex 38334フランス
EMail: vincent.roca@inria.fr
URI: http://planete.inrialpes.fr/people/roca/
Brian Adamson Naval Research Laboratory Washington, DC 20375 USA
ブライアンアダムソン海軍研究所ワシントンDC 20375アメリカ
EMail: adamson@itd.nrl.navy.mil
URI: http://cs.itd.nrl.navy.mil