[要約] RFC 9223 - Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE) は、アプリケーションオブジェクトを受信者にロバストに配信するためのプロトコルであり、リアルタイム配信制約を持つアプリケーションオブジェクトにも対応しています。ROUTEプロトコルは、低遅延ストリーミングアプリケーションにも対応し、ユニキャスト、ブロードキャスト、マルチキャスト転送に適しています。
Independent Submission W. Zia
Request for Comments: 9223 T. Stockhammer
Category: Informational Qualcomm CDMA Technologies GmbH
ISSN: 2070-1721 L. Chaponniere
G. Mandyam
Qualcomm Technologies Inc.
M. Luby
BitRipple, Inc.
April 2022
Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE)
一方向輸送（ルート）を介したリアルタイム輸送オブジェクト配信
Abstract
概要
The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol is specified for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers; for example, it can be a file, a Dynamic Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) segment, a WAV audio clip, etc. The ROUTE protocol also supports low-latency streaming applications.
単方向輸送（Route）プロトコルを介したリアルタイムトランスポートオブジェクト配信は、一方向の輸送を介したレシーバーに、リアルタイム配信制約のあるアプリケーションオブジェクトを含むアプリケーションオブジェクトの堅牢な配信用に指定されています。アプリケーションオブジェクトは、データの配信にルートプロトコルを使用するアプリケーションに意味があるデータで構成されています。たとえば、ファイル、HTTP（DASH）またはHTTPライブストリーミング（HLS）セグメントを介した動的な適応ストリーミング、WAVオーディオクリップなどです。ルートプロトコルは、低価格のストリーミングアプリケーションもサポートしています。
The ROUTE protocol is suitable for unicast, broadcast, and multicast transport. Therefore, it can be run over UDP/IP, including multicast IP. The ROUTE protocol can leverage the features of the underlying protocol layer, e.g., to provide security, it can leverage IP security protocols such as IPsec.
ルートプロトコルは、ユニキャスト、ブロードキャスト、マルチキャストトランスポートに適しています。したがって、マルチキャストIPを含むUDP/IPで実行できます。ルートプロトコルは、基礎となるプロトコル層の機能を活用できます。たとえば、セキュリティを提供するために、IPSECなどのIPセキュリティプロトコルを活用できます。
This document specifies the ROUTE protocol such that it could be used by a variety of services for delivery of Application Objects by specifying their own profiles of this protocol (e.g., by adding or constraining some features).
このドキュメントは、このプロトコルの独自のプロファイルを指定することにより、アプリケーションオブジェクトの配信のためにさまざまなサービスで使用できるようにルートプロトコルを指定します（たとえば、いくつかの機能を追加または制約することで）。
This is not an IETF specification and does not have IETF consensus.
これはIETF仕様ではなく、IETFコンセンサスはありません。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。RFCエディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。RFCエディターによって公開が承認されたドキュメントは、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9223.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9223で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction
1.1. Overview
1.2. Protocol Stack for ROUTE
1.3. Data Model
1.4. Architecture and Scope of Specification
1.5. Conventions Used in This Document
2. ROUTE Packet Format
2.1. Packet Structure and Header Fields
2.2. LCT Header Extensions
2.3. FEC Payload ID for Source Flows
2.4. FEC Payload ID for Repair Flows
3. Session Metadata
3.1. Generic Metadata
3.2. Session Metadata for Source Flows
3.3. Session Metadata for Repair Flows
4. Delivery Object Mode
4.1. File Mode
4.1.1. Extensions to FDT
4.1.2. Constraints on Extended FDT
4.2. Entity Mode
4.3. Unsigned Package Mode
4.4. Signed Package Mode
5. Sender Operation
5.1. Usage of ALC and LCT for Source Flow
5.2. ROUTE Packetization for Source Flow
5.2.1. Basic ROUTE Packetization
5.2.2. ROUTE Packetization for CMAF Chunked Content
5.3. Timing of Packet Emission
5.4. Extended FDT Encoding for File Mode Sending
5.5. FEC Framework Considerations
5.6. FEC Transport Object Construction
5.7. Super-Object Construction
5.8. Repair Packet Considerations
5.9. Summary FEC Information
6. Receiver Operation
6.1. Basic Application Object Recovery for Source Flows
6.2. Fast Stream Acquisition
6.3. Generating Extended FDT-Instance for File Mode
6.3.1. File Template Substitution for Content-Location
Derivation
6.3.2. File@Transfer-Length Derivation
6.3.3. FDT-Instance@Expires Derivation
7. FEC Application
7.1. General FEC Application Guidelines
7.2. TOI Mapping
7.3. Delivery Object Reception Timeout
7.4. Example FEC Operation
8. Considerations for Defining ROUTE Profiles
9. ROUTE Concepts
9.1. ROUTE Modes of Delivery
9.2. File Mode Optimizations
9.3. In-Band Signaling of Object Transfer Length
9.4. Repair Protocol Concepts
10. Interoperability Chart
11. Security and Privacy Considerations
11.1. Security Considerations
11.2. Privacy Considerations
12. IANA Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Authors' Addresses
The Real-time Transport Object delivery over Unidirectional Transport (ROUTE) protocol can be used for robust delivery of Application Objects, including Application Objects with real-time delivery constraints, to receivers over a unidirectional transport. Unidirectional transport in this document has identical meaning to that in RFC 6726 [RFC6726], i.e., transport in the direction of receiver(s) from a sender. The robustness is enabled by a built-in mechanism, e.g., signaling for loss detection, enabling loss recovery, and optionally integrating application-layer Forward Error Correction (FEC).
単方向輸送（ルート）プロトコルを介したリアルタイムトランスポートオブジェクトの配信は、リアルタイム配信制約のあるアプリケーションオブジェクトを含むアプリケーションオブジェクトの堅牢な配信に、単方向輸送を介した受信機に使用できます。このドキュメントの単方向輸送は、RFC 6726 [RFC6726]、つまり送信者からの受信機の方向に輸送されたものと同じ意味と同じ意味です。堅牢性は、組み込みのメカニズム、たとえば損失検出のシグナリング、損失回復を可能にし、オプションでアプリケーション層の前方エラー補正（FEC）を統合することによって有効になります。
Application Objects consist of data that has meaning to applications that use the ROUTE protocol for delivery of data to receivers, e.g., an Application Object can be a file, an MPEG Dynamic Adaptive Streaming over HTTP (DASH) [DASH] video segment, a WAV audio clip, an MPEG Common Media Application Format (CMAF) [CMAF] addressable resource, an MPEG-4 video clip, etc.
アプリケーションオブジェクトは、データを受信機に配信するためにルートプロトコルを使用するアプリケーションに意味を持つデータで構成されています。オーディオクリップ、MPEG共通メディアアプリケーション形式（CMAF）[CMAF]アドレス指定可能なリソース、MPEG-4ビデオクリップなど。
The ROUTE protocol is designed to enable delivery of sequences of related Application Objects in a timely manner to receivers, e.g., a sequence of DASH video segments associated to a Representation or a sequence of CMAF addressable resources associated to a CMAF Track. The applications of this protocol target services enabled on media consumption devices such as smartphones, tablets, television sets, and so on. Most of these applications are real-time in the sense that they are sensitive to and rely upon such timely reception of data. The ROUTE protocol also supports chunked delivery of real-time Application Objects to enable low-latency streaming applications (similar in its properties to chunked delivery using HTTP). The protocol also enables low-latency delivery of DASH and Apple HTTP Live Streaming (HLS) content with CMAF Chunks.
ルートプロトコルは、レシーバーにタイムリーに関連するアプリケーションオブジェクトのシーケンスの配信を有効にするように設計されています。たとえば、表現に関連付けられた一連のダッシュビデオセグメントまたはCMAFトラックに関連付けられたCMAFアドレス指定可能なリソースのシーケンス。このプロトコルターゲットサービスのアプリケーションは、スマートフォン、タブレット、テレビセットなどのメディア消費デバイスで有効になっています。これらのアプリケーションのほとんどは、そのようなタイムリーなデータを受信することに敏感であり、依存しているという意味でリアルタイムです。ルートプロトコルは、低遅延のストリーミングアプリケーションを有効にするために、リアルタイムアプリケーションオブジェクトのチャンク配信もサポートしています（HTTPを使用したチャンク配信と同様）。また、このプロトコルは、CMAFチャンクを使用したDashおよびApple HTTP Live Streaming（HLS）コンテンツの低遅延配信も可能にします。
Content not intended for rendering in real time as it is received (e.g., a downloaded application), a file comprising continuous or discrete media and belonging to an app-based feature, or a file containing (opaque) data to be consumed by a Digital Rights Management (DRM) system client can also be delivered by ROUTE.
受信時にリアルタイムでレンダリングすることを目的としていないコンテンツ（ダウンロードされたアプリケーションなど）、連続または個別のメディアを含むファイル、アプリベースの機能に属するファイル、またはデジタルで消費される（不透明な）データを含むファイル権利管理（DRM）システムクライアントは、ルートごとに配信することもできます。
The ROUTE protocol supports a caching model where Application Objects are recovered into a cache at the receiver and may be made available to applications via standard HTTP requests from the cache. Many current day applications rely on using HTTP to access content; hence, this approach enables such applications in broadcast/multicast environments.
ルートプロトコルは、アプリケーションオブジェクトがレシーバーのキャッシュに回復され、キャッシュから標準のHTTP要求を介してアプリケーションで利用可能にするキャッシュモデルをサポートします。多くの現在のアプリケーションは、HTTPを使用してコンテンツにアクセスすることに依存しています。したがって、このアプローチにより、このようなアプリケーションはブロードキャスト/マルチキャスト環境で可能になります。
ROUTE is aligned with File Delivery over Unidirectional Transport (FLUTE) as defined in RFC 6726 [RFC6726] as well as the extensions defined in Multimedia Broadcast/Multicast Service (MBMS) [MBMS], but it also makes use of some principles of FCAST (Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols) as defined in RFC 6968 [RFC6968]; for example, object metadata and the object content may be sent together in a compound object.
ルートは、RFC 6726 [RFC6726]で定義されている単方向輸送（フルート）を介したファイル配信と、マルチメディアブロードキャスト/マルチキャストサービス（MBMS）[MBMS]で定義されている拡張機能に沿っていますが、FCASCの原則も使用します（RFC 6968 [RFC6968]で定義されているように、非同期層コーディング（ALC）およびNACK指向の信頼できるマルチキャスト（NORM）プロトコル）のオブジェクト配信。たとえば、オブジェクトメタデータとオブジェクトコンテンツは、複合オブジェクトで一緒に送信される場合があります。
The alignment to FLUTE is enabled since in addition to reusing several of the basic FLUTE protocol features, as referred to by this document, certain optimizations and restrictions are added that enable optimized support for real-time delivery of media data; hence, the name of the protocol. Among others, the source ROUTE protocol enables or enhances the following functionalities:
このドキュメントで言及されているように、いくつかの基本的なフルートプロトコル機能を再利用することに加えて、メディアデータのリアルタイム配信の最適化されたサポートを可能にする特定の最適化と制限が追加されているため、フルートへのアライメントが有効になります。したがって、プロトコルの名前。とりわけ、ソースルートプロトコルは、次の機能を有効または強化します。
* Real-time delivery of object-based media data
* オブジェクトベースのメディアデータのリアルタイム配信
* Flexible packetization, including enabling media-aware packetization as well as transport-aware packetization of delivery objects
* メディア認識のパケット化を可能にすることや、配信オブジェクトの輸送認識パケット化を含む柔軟なパケット化
* Independence of Application Objects and delivery objects, i.e., a delivery object may be a part of a file or may be a group of files.
* アプリケーションオブジェクトと配信オブジェクトの独立性、つまり配信オブジェクトはファイルの一部である場合や、ファイルのグループである場合があります。
Advanced Television Systems Committee (ATSC) 3.0 specifies the ROUTE protocol integrated with an ATSC 3.0 services layer. That specification will be referred to as ATSC-ROUTE [ATSCA331] for the remainder of this document. Digital Video Broadcasting (DVB) has specified a profile of ATSC-ROUTE in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) [DVBMABR]. This document specifies the Application Object delivery aspects (delivery protocol) for such services, as the corresponding delivery protocol could be used as a reference by a variety of services by specifying profiles of ROUTE in their respective fora, e.g., by adding new optional features atop or by restricting various optional features specified in this document in a specific service standard. Hence, in the context of this document, the aforementioned ATSC-ROUTE and DVB-MABR are the services using ROUTE. The definition of profiles by the services also have to give due consideration to compatibility issues, and some related guidelines are also provided in this document.
Advanced Television Systems Committee（ATSC）3.0 ATSC 3.0サービスレイヤーと統合されたルートプロトコルを指定します。この仕様は、このドキュメントの残りの部分について、ATSC-Route [ATSCA331]と呼ばれます。 Digital Video Broadcasting（DVB）は、IPマルチキャスト（DVB-MABR）[DVBMABR]を介したDVB適応メディアストリーミングのATSC-Routeのプロファイルを指定しました。このドキュメントは、そのようなサービスのアプリケーションオブジェクト配信の側面（配信プロトコル）を指定します。これは、対応する配信プロトコルは、それぞれのフォーラでルートのプロファイルを指定することにより、さまざまなサービスの参照として使用できるためです。または、このドキュメントで特定のサービス標準で指定されているさまざまなオプション機能を制限することにより。したがって、このドキュメントのコンテキストでは、前述のATSC-RouteおよびDVB-MABRはルートを使用するサービスです。サービスによるプロファイルの定義も互換性の問題を十分に考慮する必要があり、いくつかの関連するガイドラインもこのドキュメントに記載されています。
This document is not an IETF specification and does not have IETF consensus. It is provided here to aid the production of interoperable implementations.
このドキュメントはIETF仕様ではなく、IETFコンセンサスはありません。ここでは、相互運用可能な実装の生産を支援するために提供されています。
ROUTE delivers Application Objects such as MPEG DASH or HLS segments and optionally the associated repair data, operating over UDP/IP networks, as depicted in Table 1. The session metadata signaling to realize a ROUTE session as specified in this document MAY be delivered out of band or in band as well. Since ROUTE delivers objects in an application cache at the receiver from where the application can access them using HTTP, an application like DASH may use its standardized unicast streaming mechanisms in conjunction with ROUTE over broadcast/multicast to augment the services.
ルートは、MPEGダッシュやHLSセグメントなどのアプリケーションオブジェクトを配信します。オプションでは、表1に示すように、UDP/IPネットワークを介して動作する関連する修理データをオプションで配信します。このドキュメントで指定されたルートセッションを実現するセッションメタデータシグナリングは、バンドまたはバンドでも。Routeは、アプリケーションがHTTPを使用してアプリケーションにアクセスできるアプリケーションキャッシュ内のオブジェクトを配信するため、DASHのようなアプリケーションは、サービスを強化するためにロートオーバーオーバーラート/マルチキャストと組み合わせて標準化されたユニキャストストリーミングメカニズムを使用できます。
+--------------------------------------------------------+
| Application (DASH and HLS segments, CMAF Chunks, etc.) |
+--------------------------------------------------------+
| ROUTE |
+--------------------------------------------------------+
| UDP |
+--------------------------------------------------------+
| IP |
+--------------------------------------------------------+
Table 1: Protocol Layering
表1：プロトコル階層化
The ROUTE data model is constituted by the following key concepts.
ルートデータモデルは、次の重要な概念によって構成されています。
Application Object: data that has meaning to the application that uses the ROUTE protocol for delivery of data to receivers, e.g., an Application Object can be a file, a DASH video segment, a WAV audio clip, an MPEG-4 video clip, etc.
アプリケーションオブジェクト：レシーバーにデータの配信にルートプロトコルを使用するアプリケーションに意味するデータ、たとえば、アプリケーションオブジェクトはファイル、ダッシュビデオセグメント、WAVオーディオクリップ、MPEG-4ビデオクリップなどです。。
Delivery Object: an object on course of delivery to the application from the ROUTE sender to ROUTE receiver.
配信オブジェクト：ルート送信者からルートレシーバーへのアプリケーションへの配信のコースでのオブジェクト。
Transport Object: an object identified by the Transport Object Identifier (TOI) in RFC 5651 [RFC5651]. It MAY be either a source or a repair object, depending on if it is carried by a Source Flow or a Repair Flow, respectively.
トランスポートオブジェクト：RFC 5651 [RFC5651]のトランスポートオブジェクト識別子（TOI）によって識別されるオブジェクト。ソースフローまたは修理フローによってそれぞれ運ばれているかどうかに応じて、ソースまたは修理オブジェクトのいずれかである場合があります。
Transport Session: a Layered Coding Transport (LCT) channel, as defined by RFC 5651 [RFC5651]. A Transport Session SHALL be uniquely identified by a unique Transport Session Identifier (TSI) value in the LCT header. The TSI is scoped by the IP address of the sender, and the IP address of the sender together with the TSI uniquely identify the session. Transport Sessions are a subset of a ROUTE session. For media delivery, a Transport Session would typically carry a media component, for example, a DASH Representation. Within each Transport Session, one or more objects are carried, typically objects that are related, e.g., DASH segments associated to one Representation.
トランスポートセッション：RFC 5651 [RFC5651]で定義されている層状コーディングトランスポート（LCT）チャネル。輸送セッションは、LCTヘッダーの一意の輸送セッション識別子（TSI）値によって一意に識別されるものとします。TSIは送信者のIPアドレスによってスコープされ、送信者のIPアドレスがTSIと一緒にセッションを一意に識別します。トランスポートセッションは、ルートセッションのサブセットです。メディア配信の場合、トランスポートセッションは通常、メディアコンポーネント、たとえばダッシュ表現を搭載します。各トランスポートセッション内では、1つ以上のオブジェクトが運ばれます。通常、関連するオブジェクト、たとえば1つの表現に関連付けられたダッシュセグメントです。
ROUTE Session: an ensemble or multiplex of one or more Transport Sessions. Each ROUTE session is associated with an IP address/ port combination. A ROUTE session typically carries one or more media components of streaming media e.g., Representations associated with a DASH Media Presentation.
ルートセッション：1つ以上のトランスポートセッションのアンサンブルまたはマルチプレックス。各ルートセッションは、IPアドレス/ポートの組み合わせに関連付けられています。ルートセッションでは、通常、ストリーミングメディアの1つ以上のメディアコンポーネント、たとえばダッシュメディアのプレゼンテーションに関連する表現を実現します。
Source Flow: a Transport Session carrying source data. Source Flow is independent of the Repair Flow, i.e., the Source Flow MAY be used by a ROUTE receiver without the ROUTE Repair Flows.
ソースフロー：ソースデータを運ぶトランスポートセッション。ソースフローは修理フローとは無関係です。つまり、ソースフローは、ルート修理フローなしでルートレシーバーによって使用される場合があります。
Repair Flow: a Transport Session carrying repair data for one or more Source Flows.
修理フロー：1つ以上のソースフローの修理データを運ぶ輸送セッション。
The scope of the ROUTE protocol is to enable robust and real-time transport of delivery objects using LCT packets. This architecture is depicted in Figure 1.
ルートプロトコルの範囲は、LCTパケットを使用して配信オブジェクトの堅牢でリアルタイムの輸送を可能にすることです。このアーキテクチャを図1に示します。
The normative aspects of the ROUTE protocol focus on the following aspects:
ルートプロトコルの規範的側面は、次の側面に焦点を当てています。
* The format of the LCT packets that carry the transport objects.
* トランスポートオブジェクトを運ぶLCTパケットの形式。
* The robust transport of the delivery object using a repair protocol based on Forward Error Correction (FEC).
* フォワードエラー補正（FEC）に基づいた修復プロトコルを使用した配信オブジェクトの堅牢な輸送。
* The definition and possible carriage of object metadata along with the delivery objects. Metadata may be conveyed in LCT packets and/or separate objects.
* 配信オブジェクトとともに、オブジェクトメタデータの定義と可能なキャリッジ。メタデータは、LCTパケットおよび/または個別のオブジェクトで伝達される場合があります。
* The ROUTE session, LCT channel, and delivery object description provided as service metadata signaling to enable the reception of objects.
* ルートセッション、LCTチャネル、および配信オブジェクトの説明は、オブジェクトの受信を可能にするサービスメタデータシグナリングとして提供されます。
* The normative aspects (formats, semantics) of the delivery objects conveyed as a content manifest to be delivered along with the objects to optimize the performance for specific applications e.g., real-time delivery. The objects and manifest are made available to the application through an Application Object cache. The interface of this cache to the application is not specified in this document; however, it will typically be enabled by the application acting as an HTTP client and the cache as the HTTP server.
* 配信オブジェクトの規範的側面（フォーマット、セマンティクス）は、特定のアプリケーションのパフォーマンスを最適化するためにオブジェクトとともに配信されるコンテンツマニフェストとして伝達されます。オブジェクトとマニフェストは、アプリケーションオブジェクトキャッシュを介してアプリケーションで利用可能になります。アプリケーションへのこのキャッシュのインターフェイスは、このドキュメントでは指定されていません。ただし、通常、HTTPクライアントとして機能するアプリケーション、およびHTTPサーバーとしてキャッシュによって機能するアプリケーションによって有効になります。
Application Objects
Application to application
Objects from ^
an application +--------------------------------------------+
+ | ROUTE Receiver | |
| | +------+------+ |
| | | Application | |
| | | Object Cache| |
| | +------+------+ |
| LCT over| +---------------+ ^ |
v UDP/IP | | Source object | +---------+ | |
+----+---+ | +->+ recovery +--+ Repair +-+ |
| ROUTE | | | +---------------+ +----+----+ |
| Sender +----------+ ^ |
+----+---+ | | | |
| | | +---------------+ | |
| | | | Repair object | | |
| | +->+ recovery +-------+ |
+----------->+ +---------------+ |
ROUTE | |
Metadata +--------------------------------------------+
Figure 1: Architecture/Functional Block Diagram
図1：アーキテクチャ/機能ブロック図
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The packet format used by ROUTE Source Flows and Repair Flows follows the ALC packet format specified in RFC 5775 [RFC5775] with the UDP header followed by the default LCT header and the source FEC Payload ID followed by the packet payload. The overall ROUTE packet format is as depicted in Figure 2.
ルートソースフローと修理フローで使用されるパケット形式は、RFC 5775 [RFC5775]で指定されたALCパケット形式に続き、UDPヘッダーに続いてデフォルトのLCTヘッダーとソースFECペイロードIDがパケットペイロードが続きます。全体のルートパケット形式は、図2に示すとおりです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header |
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Default LCT header |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC Payload ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Data |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Overall ROUTE Packet Format
図2：全体のルートパケット形式
The Default LCT header is as defined in the LCT building block in RFC 5651 [RFC5651].
デフォルトのLCTヘッダーは、RFC 5651 [RFC5651]のLCTビルディングブロックで定義されています。
The LCT packet header fields SHALL be used as defined by the LCT building block in RFC 5651 [RFC5651]. The semantics and usage of the following LCT header fields SHALL be further constrained in ROUTE as follows:
LCTパケットヘッダーフィールドは、RFC 5651 [RFC5651]のLCTビルディングブロックで定義されているように使用するものとします。次のLCTヘッダーフィールドのセマンティクスと使用は、次のようにルートでさらに制約されるものとします。
Version number (V): This 4-bit field indicates the protocol version number. The version number SHALL be set to '0001', as specified in RFC 5651 [RFC5651].
バージョン番号（v）：この4ビットフィールドは、プロトコルバージョン番号を示します。バージョン番号は、RFC 5651 [RFC5651]で指定されているように、「0001」に設定されます。
Congestion Control flag (C) field: This 2-bit field, as defined in RFC 5651 [RFC5651], SHALL be set to '00'.
混雑制御フラグ（c）フィールド：RFC 5651 [RFC5651]で定義されているこの2ビットフィールドは、「00」に設定するものとします。
Protocol-Specific Indication (PSI): The most significant bit of this 2-bit flag is called the Source Packet Indicator (SPI) and indicates whether the current packet is a source packet or a FEC repair packet. The SPI SHALL be set to '1' to indicate a source packet and SHALL bet set to '0' to indicate a repair packet.
プロトコル固有の表示（PSI）：この2ビットフラグの中で最も重要なビットは、ソースパケットインジケーター（SPI）と呼ばれ、現在のパケットがソースパケットかFEC修理パケットかを示します。SPIは、ソースパケットを示すために「1」に設定され、修理パケットを示すように「0」に設定されます。
Transport Session Identifier flag (S): This 1-bit field SHALL be set to '1' to indicate a 32-bit word in the TSI field.
トランスポートセッション識別子フラグ：この1ビットフィールドは、TSIフィールドに32ビットワードを示すために「1」に設定する必要があります。
Transport Object Identifier flag (O): This 2-bit field SHALL be set to '01' to indicate the number of full 32-bit words in the TOI field.
トランスポートオブジェクト識別子フラグ（O）：この2ビットフィールドは、TOIフィールドの完全な32ビット単語の数を示すために「01」に設定する必要があります。
Half-word flag (H): This 1-bit field SHALL be set to '0' to indicate that no half-word field sizes are used.
ハーフワードフラグ（H）：この1ビットフィールドは、ハーフワードフィールドサイズが使用されないことを示すために「0」に設定する必要があります。
Codepoint (CP): This 8-bit field is used to indicate the type of the payload that is carried by this packet; for ROUTE, it is defined as shown below to indicate the type of delivery object carried in the payload of the associated ROUTE packet. The remaining unmapped Codepoint values can be used by a service using ROUTE. In this case, the Codepoint values SHALL follow the semantics specified in the following table. "IS" stands for Initialization Segment of the media content such as the DASH Initialization Segment [DASH]. The various modes of operation in the table (File/Entity/Package Mode) are specified in Section 4. The table also lists a Codepoint value range that is reserved for future service-specific uses.
CodePoint（CP）：この8ビットフィールドは、このパケットによって運ばれるペイロードのタイプを示すために使用されます。ルートの場合、関連するルートパケットのペイロードで運ばれる配信オブジェクトのタイプを示すために、以下に示すように定義されます。残りのマップされていないCodePoint値は、ルートを使用してサービスで使用できます。この場合、コードポイント値は、次の表に指定されたセマンティクスに従うものとします。「IS」は、DASH初期化セグメント[DASH]などのメディアコンテンツの初期化セグメントの略です。テーブル内のさまざまな操作モード（ファイル/エンティティ/パッケージモード）をセクション4で指定します。表には、将来のサービス固有の用途向けに予約されているコードポイント値範囲もリストされています。
+=================+=================================+
| Codepoint value | Semantics |
+=================+=================================+
| 0 | Reserved (not used) |
+-----------------+---------------------------------+
| 1 | Non Real Time (NRT) - File Mode |
+-----------------+---------------------------------+
| 2 | NRT - Entity Mode |
+-----------------+---------------------------------+
| 3 | NRT - Unsigned Package Mode |
+-----------------+---------------------------------+
| 4 | NRT - Signed Package Mode |
+-----------------+---------------------------------+
| 5 | New IS, timeline changed |
+-----------------+---------------------------------+
| 6 | New IS, timeline continued |
+-----------------+---------------------------------+
| 7 | Redundant IS |
+-----------------+---------------------------------+
| 8 | Media Segment, File Mode |
+-----------------+---------------------------------+
| 9 | Media Segment, Entity Mode |
+-----------------+---------------------------------+
| 10 | Media Segment, File Mode with |
| | CMAF Random Access chunk |
+-----------------+---------------------------------+
| 11 - 255 | Reserved, service-specific |
+-----------------+---------------------------------+
Table 2: Codepoint Values
表2：コードポイント値
Congestion Control Information (CCI): For packets carrying DASH segments, CCI MAY convey the 32-bit earliest presentation time [DASH] of the DASH segment contained in the ROUTE packet. In this case, this information can be used by a ROUTE receiver for fast stream acquisition (details in Section 6.2). Otherwise, this field SHALL be set to 0.
輻輳制御情報（CCI）：ダッシュセグメントを運ぶパケットの場合、CCIは、ルートパケットに含まれるダッシュセグメントの32ビット初期のプレゼンテーション時間[DASH]を伝えることができます。この場合、この情報は、高速ストリーム取得のためにルートレシーバーによって使用できます（セクション6.2の詳細）。それ以外の場合、このフィールドは0に設定するものとします。
Transport Session Identifier (TSI): This 32-bit field identifies the Transport Session in ROUTE. The context of the Transport Session is provided by signaling metadata. The value TSI = 0 SHALL only be used for service-specific signaling.
トランスポートセッション識別子（TSI）：この32ビットフィールドは、ルート内の輸送セッションを識別します。輸送セッションのコンテキストは、シグナリングメタデータによって提供されます。値TSI = 0は、サービス固有のシグナル伝達にのみ使用されます。
Transport Object Identifier (TOI): This 32-bit field SHALL identify the object within this session to which the payload of the current packet belongs. The mapping of the TOI field to the object is provided by the Extended File Delivery Table (FDT).
トランスポートオブジェクト識別子（TOI）：この32ビットフィールドは、現在のパケットのペイロードが属するこのセッション内のオブジェクトを識別するものとします。TOIフィールドのオブジェクトへのマッピングは、拡張ファイル配信テーブル（FDT）によって提供されます。
The following LCT header extensions are defined or used by ROUTE:
次のLCTヘッダー拡張機能は、ルートで定義または使用されます。
EXT_FTI: as specified in RFC 5775.
ext_fti：RFC 5775で指定されています。
EXT_TOL: the length in bytes of the multicast transport object shall be signaled using EXT_TOL as specified by ATSC-ROUTE [ATSCA331] with 24 bits or, if required, 48 bits of Transfer Length. The frequency of using the EXT_TOL header extension is determined by channel conditions that may cause the loss of the packet carrying the Close Object flag (B) [RFC5651].
ext_tol：マルチキャストトランスポートオブジェクトのバイト単位の長さは、24ビットまたは必要に応じて48ビットのトランスファー長でATSC-Route [ATSCA331]で指定されているext_TOLを使用して信号を送信する必要があります。ext_tolヘッダー拡張機能を使用する頻度は、クローズオブジェクトフラグ（b）[RFC5651]を運ぶパケットの損失を引き起こす可能性のあるチャネル条件によって決定されます。
NOTE: The transport object length can also be determined without the use of EXT_TOL by examining the LCT packet with the Close Object flag (B). However, if this packet is lost, then the EXT_TOL information can be used by the receiver to determine the transport object length.
注：輸送オブジェクトの長さは、Closeオブジェクトフラグ（b）を使用してLCTパケットを調べることにより、ext_tolを使用せずに決定することもできます。ただし、このパケットが失われた場合、ext_tol情報をレシーバーが使用して、トランスポートオブジェクトの長さを決定できます。
EXT_TIME Header: as specified in RFC 5651 [RFC5651]. The Sender Current Time SHALL be signaled using EXT_TIME.
ext_timeヘッダー：RFC 5651 [RFC5651]で指定されています。送信者の現在の時刻は、ext_timeを使用して信号を受けるものとします。
The syntax of the FEC Payload ID for the Compact No-Code FEC Scheme used in ROUTE Source Flows is a 32-bit unsigned integer value that SHALL express the start_offset as an octet number corresponding to the first octet of the fragment of the delivery object carried in this packet. The start_offset value for the first fragment of any delivery object SHALL be set to 0. Figure 3 shows the 32-bit start_offset field.
ルートソースフローで使用されるコンパクトノーコードFECスキームのFECペイロードIDの構文は、配信オブジェクトの断片の最初のオクテットに対応するoccet _ offsetをstart_offsetを運びます。このパケットで。配信オブジェクトの最初のフラグメントのstart_offset値は、0に設定する必要があります。図3は、32ビットstart_offsetフィールドを示しています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| start_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: FEC Payload ID for Source Flows
図3：ソースフローのFECペイロードID
FEC Payload ID for Repair Flows is specified in RFC 6330 [RFC6330].
修復フローのFECペイロードIDは、RFC 6330 [RFC6330]で指定されています。
The required session metadata for Source and Repair Flows is specified in the following sections. The list specified here is not exhaustive; a service MAY signal more metadata to meet its needs. The data format is also not specified beyond its cardinality; the exact format of specifying the data is left for the service, e.g., by using XML encoding format, as has been done by [DVBMABR] and [ATSCA331]. It is specified in the following if an attribute is mandatory (m), conditional mandatory (cm) or optional (o) to realize a basic ROUTE session. A mandatory field SHALL always be present in the session metadata, and a conditional mandatory field SHALL be present if the specified condition is true. The delivery of the session metadata to the ROUTE receiver is beyond the scope of this document.
ソースおよび修理フローに必要なセッションメタデータは、次のセクションで指定されています。ここで指定されているリストは網羅的ではありません。サービスは、そのニーズを満たすために、より多くのメタデータを知らせることができます。データ形式は、その枢機inalを超えて指定されていません。データを指定する正確な形式は、[DVBMABR]および[ATSCA331]によって行われたように、XMLエンコード形式を使用することにより、サービスに残されます。基本的なルートセッションを実現するために、属性が必須（m）、条件付き必須（cm）、またはオプション（o）である場合、以下で指定されます。必須フィールドは常にセッションメタデータに存在し、指定された条件が真である場合は条件付き必須フィールドが存在するものとします。ルートレシーバーへのセッションメタデータの配信は、このドキュメントの範囲を超えています。
Generic metadata is applicable to both Source and Repair Flows as follows. Before a receiver can join a ROUTE session, the receiver needs to obtain this generic metadata that contains at least the following information:
一般的なメタデータは、次のように、ソースフローと修復フローの両方に適用できます。受信者がルートセッションに参加する前に、受信者は少なくとも次の情報を含むこの一般的なメタデータを取得する必要があります。
ROUTE version number (m): the version number of ROUTE used in this session. The version number conforming to this document SHALL be 1.
ルートバージョン番号（m）：このセッションで使用されるルートのバージョン番号。このドキュメントに準拠しているバージョン番号は1です。
Connection ID (m): the unique identifier of a Connection, usually consisting of the following 4-tuple: source IP address/source port number, destination IP address/destination port number. The IP addresses can be IPv4 or IPv6 addresses depending upon which IP version is used by the deployment.
接続ID（M）：通常、次の4タプルで構成される接続の一意の識別子：ソースIPアドレス/ソースポート番号、宛先IPアドレス/宛先ポート番号。IPアドレスは、展開によって使用されるIPバージョンに応じて、IPv4またはIPv6アドレスにすることができます。
stsi (m): The LCT TSI value corresponding to the Transport Session for the Source Flow.
STSI（M）：ソースフローのトランスポートセッションに対応するLCT TSI値。
rt (o): A Boolean flag that SHALL indicate whether the content component carried by this Source Flow corresponds to real-time streaming media or non-real-time content. When set to "true", it SHALL be an indication of real-time content, and when absent or set to "false", it SHALL be an indication of non-real-time (NRT) content.
RT（O）：このソースフローによって運ばれるコンテンツコンポーネントが、リアルタイムストリーミングメディアまたは非リアルタイムコンテンツに対応するかどうかを示すブールフラグ。「true」に設定する場合、それはリアルタイムコンテンツの兆候であり、「false」を欠席または設定する場合、非リアルタイム（NRT）コンテンツの兆候となります。
minBufferSize (o): A 32-bit unsigned integer that SHALL represent, in kilobytes, the minimum required storage size of the receiver transport buffer for the parent LCT channel of this Source Flow. The buffer holds the data belonging to a source object until its complete reception. This attribute is only applicable when rt = "true".
MinbufferSize（O）：キロバイトでは、このソースフローの親LCTチャネルにレシーバー輸送バッファーの最小必要なストレージサイズを表す32ビットの非署名整数を表します。バッファは、完全な受信までソースオブジェクトに属するデータを保持します。この属性は、rt = "true"の場合にのみ適用されます。
A service that chooses not to signal this attribute relies on the receiver implementation, which must discard the received data beyond its buffering capability. Such discarding of data will impact the service quality.
この属性を信号しないことを選択するサービスは、受信者の実装に依存しているため、受信したデータをバッファリング機能を超えて破棄する必要があります。このようなデータの破棄は、サービス品質に影響を与えます。
EFDT (cm): When present, SHALL contain a single instance of an FDT-Instance element per RFC 6726 FLUTE [RFC6726], which MAY contain the optional FDT extensions as defined in Section 4.1. The optional EFDT element MAY only be present for File Mode of delivery. In File Mode, it SHALL be present if this Source Flow transports streaming media segments.
EFDT（CM）：存在する場合、RFC 6726フルート[RFC6726]ごとにFDTインスタンス要素の単一インスタンスが含まれます。オプションのEFDT要素は、ファイルモードの配信にのみ存在する場合があります。ファイルモードでは、このソースフローがストリーミングメディアセグメントを輸送する場合、存在します。
contentType (o): A string that SHALL represent the media type for the media content. It SHALL obey the semantics of the Content-Type header as specified by the HTTP/1.1 protocol in RFC 7231 [RFC7231]. This document does not define any new contentType strings. In its absence, the signaling of media type for the media content is beyond the scope of this document.
ContentType（O）：メディアコンテンツのメディアタイプを表す文字列。RFC 7231 [RFC7231]のHTTP/1.1プロトコルで指定されているコンテンツタイプのヘッダーのセマンティクスに従うものとします。このドキュメントは、新しいContentType文字列を定義しません。その不在では、メディアコンテンツのメディアタイプのシグナル伝達は、このドキュメントの範囲を超えています。
applicationMapping (m): A set of identifiers that provide an application-specific mapping of the received Application Objects to the Source Flows. For example, for DASH, this would provide the mapping of a Source Flow to a specific DASH Representation from a Media Presentation Description (MPD), the latter identified by its Representation and corresponding Adaptation Set and Period IDs.
アプリケーションマッピング（M）：受信したアプリケーションオブジェクトのアプリケーション固有のマッピングをソースフローに提供する識別子のセット。たとえば、DASHの場合、これにより、メディアプレゼンテーションの説明（MPD）から特定のDASH表現へのソースフローのマッピングが提供されます。
minBuffSize (o): A 32-bit unsigned integer whose value SHALL represent a required size of the receiver transport buffer for AL-FEC decoding processing. When present, this attribute SHALL indicate the minimum buffer size that is required to handle all associated objects that are assigned to a super-object, i.e., a delivery object formed by the concatenation of multiple FEC transport objects in order to bundle these FEC transport objects for AL-FEC protection.
Minbuffsize（O）：AL-FECデコード処理に必要なサイズの受信機輸送バッファーを表す32ビットの署名整数整数。存在する場合、この属性は、スーパーオブジェクトに割り当てられたすべての関連するオブジェクト、つまりこれらのFECトランスポートオブジェクトを束ねるために複数のFEC輸送オブジェクトの連結によって形成される配信オブジェクトを処理するために必要な最小バッファサイズを示すものとします。AL-FEC保護用。
A service that chooses not to signal this attribute relies on the receiver implementation, which must discard the received repair data beyond its buffering capability. Such discarding of data will impact the service quality.
この属性を信号しないことを選択するサービスは、受信者の実装に依存しているため、受信した修理データをバッファリング機能を超えて破棄する必要があります。このようなデータの破棄は、サービス品質に影響を与えます。
fecOTI (m): A parameter consisting of the concatenation of Common and Scheme-Specific FEC Object Transmission Information (FEC OTI) as defined in Sections 3.3.2 and 3.3.3 of [RFC6330] and that corresponds to the delivery objects carried in the Source Flow to which this Repair Flow is associated, with the following qualification: the 40-bit Transfer Length (F) field may either represent the actual size of the object, or it is encoded as all zeroes. In the latter case, the FEC transport object size either is unknown or cannot be represented by this attribute. In other words, for the all-zeroes format, the delivery objects in the Source Flow correspond to streaming content, either a live Service whereby content encoding has not yet occurred at the time this session data was generated or pre-recorded streaming content whose delivery object sizes, albeit known at the time of session data generation, are variable and cannot be represented as a single value by the fecOTI attribute.
Fecoti（M）：[RFC6330]のセクション3.3.2および3.3.3で定義されている共通およびスキーム固有のFECオブジェクト伝送情報（FEC OTI）の連結からなるパラメーター。この修復フローが関連付けられているソースフローと、次の資格とともに：40ビット転送長（f）フィールドは、オブジェクトの実際のサイズを表すか、すべてのゼロとしてエンコードされます。後者の場合、FECトランスポートオブジェクトのサイズは不明であるか、この属性で表現できません。言い換えれば、全ゼロ形式の場合、ソースフローの配信オブジェクトは、ストリーミングコンテンツに対応しています。このセッションデータが生成された時点でコンテンツエンコードが発生していないライブサービス、または配信のあるストリーミングコンテンツを事前に録音したストリーミングコンテンツのいずれかセッションデータ生成の時点で知られているにもかかわらず、オブジェクトサイズは可変であり、Fecoti属性によって単一の値として表現することはできません。
ptsi (m): TSI value(s) of each Source Flow protected by this Repair Flow.
PTSI（M）：この修復フローによって保護された各ソースフローのTSI値。
mappingTOIx (o): Values of the constant X for use in deriving the TOI of the delivery object of each protected Source Flow from the TOI of the FEC (super-)object. The default value is "1". Multiple mappingTOIx values MAY be provided for each protected Source Flow depending upon the usage of FEC (super-)object.
MappingToix（O）：FEC（Super-）オブジェクトのTOIから保護された各ソースフローの配信オブジェクトのTOIを導出する際に使用する定数Xの値。デフォルト値は「1」です。FEC（スーパー）オブジェクトの使用に応じて、保護されたソースフローごとに複数のマッピング値が提供される場合があります。
mappingTOIy (o): The corresponding constant Y to each mappingTOIx, when present, for use in deriving the parent SourceTOI value from the above equation. The default value is "0".
MappingToiy（o）：上記の方程式から親Sourcetoi値を導出するのに使用するために、存在する場合、各マッピングToixに対応する定数Y。デフォルト値は「0」です。
ROUTE provides several different delivery object modes, and one of these modes may suit the application needs better for a given Transport Session. A delivery object is self contained for the application, typically associated with certain properties, metadata, and timing-related information relevant to the application. The signaling of the delivery object mode is done on an object basis using Codepoint as specified in Section 2.1.
ルートはいくつかの異なる配信オブジェクトモードを提供し、これらのモードの1つは、特定の輸送セッションに対してアプリケーションのニーズに適している場合があります。配信オブジェクトは、通常、特定のプロパティ、メタデータ、およびアプリケーションに関連するタイミング関連情報に関連付けられているアプリケーション用に自己封じ込められています。配信オブジェクトモードの信号は、セクション2.1で指定されているCodePointを使用してオブジェクトベースで実行されます。
File Mode uses an out-of-band Extended FDT (EFDT) signaling for recovery of delivery objects with the following extensions and considerations.
ファイルモードは、以下の拡張と考慮事項を備えた配信オブジェクトの回復のために、バンド外の拡張FDT（EFDT）シグナルを使用します。
The following extensions are specified to FDT, as specified in RFC 6726 [RFC6726]. An Extended FDT-Instance is an instance of FLUTE FDT, as specified in [RFC6726], plus optionally one or more of the following extensions:
RFC 6726 [RFC6726]で指定されているように、以下の拡張はFDTに指定されています。拡張FDTインスタンスは、[RFC6726]で指定されているフルートFDTのインスタンスと、オプションで次の1つ以上の拡張機能の1つです。
efdtVersion: A value that SHALL represent the version of this Extended FDT-Instance.
efdtversion：この拡張されたFDTインスタンスのバージョンを表す値。
maxExpiresDelta: Let "tp" represent the wall clock time at the receiver when the receiver acquires the first ROUTE packet carrying data of the object described by this Extended FDT-Instance. maxExpiresDelta, when present, SHALL represent a time interval that when added to "tp" SHALL represent the expiration time of the associated Extended FDT-Instance "te". The time interval is expressed in number of seconds. When maxExpiresDelta is not present, the expiration time of the Extended FDT-Instance SHALL be given by the sum of a) the value of the ERT field in the EXT_TIME LCT header extension in the first ROUTE packet carrying data of that file, and b) the current receiver time when parsing the packet header of that ROUTE packet. See Sections 5.4 and 6.3.3 on additional rules for deriving the Extended FDT-Instance expiration time. Hence, te = tp + maxExpiresDelta
maxexpiresdelta：レシーバーがこの拡張されたFDTインスタンスで記述されたオブジェクトのデータを運ぶ最初のルートパケットを取得するとき、レシーバーの壁の時計時間を「tp」と表現します。MaxExpiresDeltaは、存在する場合、「TP」に追加された場合、関連する拡張FDTインスタンス「TE」の有効期限を表す時間間隔を表します。時間間隔は秒数で表されます。maxexpiresdeltaが存在しない場合、拡張されたFDTインスタンスの有効期限は、a）そのファイルのデータを運ぶ最初のルートパケットにおけるext_time lctヘッダー拡張におけるERTフィールドの値の合計とbの合計によって与えられます。そのルートパケットのパケットヘッダーを解析する現在の受信時間。拡張されたFDTインスタンスの有効期限を導き出すための追加のルールについては、セクション5.4および6.3.3を参照してください。したがって、te = tp maxexpiresdelta
maxTransportSize: An attribute that SHALL represent the maximum transport size in bytes of any delivery object described by this Extended FDT-Instance. This attribute SHALL be present if a) the fileTemplate is present in Extended FDT-Instance, or b) one or more File elements, if present in this Extended FDT-Instance, do not include the Transfer-Length attribute. When maxTransportSize is not present, the maximum transport size is not signaled, while other signaling such as the Transfer-Length attribute signal the exact Transfer Length of the object.
MaxTransportsize：この拡張されたFDTインスタンスで説明されている配信オブジェクトのバイトの最大輸送サイズを表す属性。この属性は、a）拡張FDTインスタンスにfiletemplateが存在する場合、またはb）1つ以上のファイル要素がこの拡張されたFDTインスタンスに存在する場合、転送長属性を含めない場合、存在するものとします。MaxTransportsizeが存在しない場合、最大輸送サイズは信号されませんが、トランスファーレングスの属性などの他のシグナル伝達は、オブジェクトの正確な転送長を信号します。
fileTemplate: A string value, which when present and in conjunction with parameter substitution, is used in deriving the Content-Location attribute for the delivery object described by this Extended FDT-Instance. It SHALL include the "$TOI$" identifier. Each identifier MAY be suffixed as needed by specific file names within the enclosing '$' characters following this prototype: %0[width]d
FileTemplate：存在する場合、パラメーター置換と組み合わせた文字列値は、この拡張されたFDTインスタンスで記述された配信オブジェクトのコンテンツロケーション属性の導出に使用されます。「$ toi $」識別子が含まれます。各識別子は、このプロトタイプに続く囲まれた「$」文字内の特定のファイル名によって必要に応じて接尾辞を受けることができます：％0 [width] d
The width parameter is an unsigned integer that provides the minimum number of characters to be printed. If the value to be printed is shorter than this number, the result SHALL be padded with leading zeroes. The value is not truncated even if the result is larger. When no format tag is present, a default format tag with width=1 SHALL be used.
幅パラメーターは、印刷する最小数の文字を提供する署名のない整数です。印刷される値がこの数値よりも短い場合、結果は先行ゼロでパッドで埋められます。結果が大きい場合でも、値は切り捨てられません。フォーマットタグが存在しない場合、width = 1のデフォルトのフォーマットタグを使用するものとします。
Strings other than identifiers SHALL only contain characters that are permitted within URIs according to RFC 3986 [RFC3986].
識別子以外の文字列には、RFC 3986 [RFC3986]に従ってURI内で許可されている文字のみが含まれているものとします。
$$ is an escape sequence in fileTemplate value, i.e., "$$" is non-recursively replaced with a single "$".
$$は、FileTemplate値のエスケープシーケンスです。つまり、「$$」は単一の「$」で非再帰的に置き換えられます。
The usage of fileTemplate is described in Sender and Receiver operations in Sections 5.4 and 6.3, respectively.
FileTemplateの使用法は、それぞれセクション5.4および6.3の送信者および受信機の操作で説明されています。
The Extended FDT-Instance SHALL conform to an FDT-Instance according to RFC 6726 [RFC6726] with the following constraints: at least one File element and the @Expires attribute SHALL be present.
拡張されたFDTインスタンスは、RFC 6726 [RFC6726]に従ってFDTインスタンスに準拠し、次の制約を備えています。少なくとも1つのファイル要素と @Expires属性が存在するものとします。
Content encoding MAY be used for delivery of any file described by an FDT-Instance.File element in the Extended FDT-Instance. The content encoding defined in the present document is gzip [RFC1952]. When content encoding is used, the File@Content-Encoding and File@Content-Length attributes SHALL be present in the Extended FDT-Instance.
コンテンツエンコーディングは、拡張FDTインスタンスのFDT-Instance.file要素によって記述されたファイルの配信に使用できます。現在のドキュメントで定義されているコンテンツは、GZIP [RFC1952]です。コンテンツエンコーディングを使用する場合、File@content-Encodingとfile@content-Length属性が拡張FDTインスタンスに存在するものとします。
For Entity Mode, the following applies:
エンティティモードの場合、次のものが適用されます。
* Delivery object metadata SHALL be expressed in the form of entity headers as defined in HTTP/1.1, which correspond to one or more of the representation header fields, payload header fields, and response header fields as defined in Sections 3.1, 3.3, and 7, respectively, of [RFC7231].
* 配信オブジェクトメタデータは、HTTP/1.1で定義されているエンティティヘッダーの形で表現するものとします。これは、セクション3.1、3.3、および7で定義されている表現ヘッダーフィールド、ペイロードヘッダーフィールド、および応答ヘッダーフィールドに対応します。それぞれ[RFC7231]の。
* The entity headers sent along with the delivery object provide all information about that multicast transport object.
* 配信オブジェクトと一緒に送信されるエンティティヘッダーは、そのマルチキャストトランスポートオブジェクトに関するすべての情報を提供します。
* Sending a media object (if the object is chunked) in Entity Mode may result in one of the following options:
* エンティティモードでメディアオブジェクト（オブジェクトがチャンクされている場合）を送信すると、次のオプションのいずれかが得られる場合があります。
- If the length of the chunked object is known at the sender, the ROUTE Entity Mode delivery object MAY be sent without using HTTP/1.1 chunked transfer coding, i.e., the object starts with an HTTP header containing the Content Length field followed by the concatenation of CMAF Chunks:
- チャンクされたオブジェクトの長さが送信者で知られている場合、ルートエンティティモード配信オブジェクトは、HTTP/1.1チャンク転送コーディングを使用せずに送信できます。CMAFチャンク：
|HTTP Header+Length||---chunk ----||---chunk ----||---chunk --
--||---chunk ----|
- If the length of the chunked object is unknown at the sender when starting to send the object, HTTP/1.1 chunked transfer coding format SHALL be used:
- チャンクされたオブジェクトの長さがオブジェクトの送信を開始したときに送信者で不明である場合、HTTP/1.1チャンク転送コーディング形式を使用するものとします。
|HTTP Header||Separator+Length||---chunk ----
||Separator+Length||---chunk ----||Separator+Length||---chunk
----||Separator+Length||---chunk ----||Separator+Length=0|
Note, however, that it is not required to send a CMAF Chunk in exactly one HTTP chunk.
ただし、1つのHTTPチャンクでCMAFチャンクを送信する必要はないことに注意してください。
In this delivery mode, the delivery object consists of a group of files that are packaged for delivery only. If applied, the client is expected to unpack the package and provide each file as an independent object to the application. Packaging is supported by Multipart Multipurpose Internet Mail Extensions (MIME) [RFC2557], where objects are packaged into one document for transport, with Content-Type set to multipart/related. When binary files are included in the package, Content-Transfer-Encoding of "binary" should be used for those files.
この配信モードでは、配信オブジェクトは、配信のためだけにパッケージ化されたファイルのグループで構成されています。適用された場合、クライアントはパッケージを開梱し、各ファイルをアプリケーションに独立したオブジェクトとして提供することが期待されます。パッケージングは、マルチパートマルチパスインターネットメールエクステンション（MIME）[RFC2557]によってサポートされています。ここでは、オブジェクトは輸送用の1つのドキュメントにパッケージ化され、コンテンツタイプはMultiPart/関連するように設定されています。バイナリファイルがパッケージに含まれている場合、「バイナリ」のコンテンツ転移エンコードを使用する必要があります。
In Signed Package Mode delivery, the delivery object consists of a group of files that are packaged for delivery, and the package includes one or more signatures for validation. Signed packaging is supported by RFC 8551 Secure MIME (S/MIME) [RFC8551], where objects are packaged into one document for transport and the package includes objects necessary for validation of the package.
署名されたパッケージモード配信では、配信オブジェクトは配信用にパッケージ化されたファイルのグループで構成され、パッケージには検証用の1つ以上の署名が含まれています。署名されたパッケージは、RFC 8551 Secure Mime（S/MIME）[RFC8551]によってサポートされています。ここでは、オブジェクトはトランスポートのために1つのドキュメントにパッケージ化され、パッケージにはパッケージの検証に必要なオブジェクトが含まれます。
ROUTE Source Flow carries the source data as specified in RFC 5775 [RFC5775]. There are several special considerations that ROUTE introduces to the usage of the LCT building block as outlined in the following:
ルートソースフローには、RFC 5775 [RFC5775]で指定されているソースデータが搭載されています。以下で概説されているように、ルートがLCTビルディングブロックの使用を導入するいくつかの特別な考慮事項があります。
* ROUTE limits the usage of the LCT building block to a single channel per session. Congestion control is thus sender driven in ROUTE. It also signifies that there is no specific congestion-control-related signaling from the sender to the receiver; the CCI field is either set to 0 or used for other purposes as specified in Section 2.1. The functionality of receiver-driven layered multicast may still be offered by the application, allowing the receiver application to select the appropriate delivery session based on the bandwidth requirement of that session.
* ルートは、LCTビルディングブロックの使用をセッションごとに単一のチャネルに制限します。したがって、混雑制御は、ルート内で送信者駆動型です。また、送信者から受信機への特定の輻輳制御関連のシグナルがないことも意味します。CCIフィールドは、セクション2.1で指定されているように、0に設定されるか、他の目的に使用されます。受信機駆動型の層状マルチキャストの機能は、アプリケーションによって引き続き提供される場合があり、受信機アプリケーションはそのセッションの帯域幅要件に基づいて適切な配信セッションを選択できます。
Further, the following details apply to LCT:
さらに、次の詳細がLCTに適用されます。
* The Layered Coding Transport (LCT) Building Block as defined in RFC 5651 [RFC5651] is used with the following constraints:
* RFC 5651 [RFC5651]で定義されている層状コーディングトランスポート（LCT）ビルディングブロックは、次の制約とともに使用されます。
- The TSI in the LCT header SHALL be set equal to the value of the stsi attribute in Section 3.2.
- LCTヘッダーのTSIは、セクション3.2のSTSI属性の値に等しく設定するものとします。
- The Codepoint (CP) in the LCT header SHALL be used to signal the applied formatting as defined in the signaling metadata.
- LCTヘッダーのCodePoint（CP）を使用して、シグナルメタデータで定義されているように適用されたフォーマットを信号します。
- In accordance with ALC, a source FEC Payload ID header is used to identify, for FEC purposes, the encoding symbols of the delivery object, or a portion thereof, carried by the associated ROUTE packet. This information may be sent in several ways:
- ALCに従って、ソースFECペイロードIDヘッダーを使用して、FECの目的で、配信オブジェクトのエンコード記号、または関連するルートパケットによって運ばれるその一部を識別します。この情報はいくつかの方法で送信される場合があります。
o As a simple new null FEC scheme with the following usage:
o 次の使用法を備えた単純な新しいヌルFECスキームとして：
+ The value of the source FEC Payload ID header SHALL be set to 0 in case the ROUTE packet contains the entire delivery object, or
+ ソースFECペイロードIDヘッダーの値は、ルートパケットに配信オブジェクト全体が含まれている場合に0に設定する必要があります。
+ The value of the source FEC Payload ID header SHALL be set as a direct address (start offset) corresponding to the starting byte position of the portion of the object carried in this packet using a 32-bit field.
+ ソースFECペイロードIDヘッダーの値は、32ビットフィールドを使用してこのパケットに掲載されたオブジェクトの部分の開始バイト位置に対応する直接アドレス（開始オフセット）として設定する必要があります。
o In a compatible manner to RFC 6330 [RFC6330] where the SBN and ESI defines the start offset together with the symbol size T.
o RFC 6330 [RFC6330]と互換性のある方法で、SBNとESIはシンボルサイズTとともに開始オフセットを定義します。
o The signaling metadata provides the appropriate parameters to indicate any of the above modes using the srcFecPayloadId attribute.
o シグナリングメタデータは、SRCFECPayLoadID属性を使用して上記のモードのいずれかを示す適切なパラメーターを提供します。
* The LCT Header EXT_TIME extension as defined in RFC 5651 [RFC5651] MAY be used by the sender in the following manner:
* RFC 5651 [RFC5651]で定義されているLCTヘッダーext_time拡張機能は、次の方法で送信者によって使用できます。
- The Sender Current Time (SCT), depending on the application, MAY be used to occasionally or frequently signal the sender current time possibly for reliever time synchronization.
- Sender Current Time（SCT）は、アプリケーションに応じて、救援者の時間同期のために、おそらく送信者の現在の時間を時々または頻繁に信号するために使用できます。
- The Expected Residual Time (ERT) MAY be used to indicate the expected remaining time for transmission of the current object in order to optimize detection of a lost delivery object.
- 予想される残差時間（ERT）を使用して、失われた配信オブジェクトの検出を最適化するために、現在のオブジェクトの伝送に予想される残り時間を示すことができます。
- The Sender Last Changed (SLC) flag is typically not utilized but MAY be used to indicate the addition/removal of Segments.
- 送信者は最後に変更された（SLC）フラグは通常使用されませんが、セグメントの添加/除去を示すために使用できます。
Additional extension headers MAY be used to support real-time delivery. Such extension headers are defined in Section 2.1.
追加の拡張ヘッダーを使用して、リアルタイム配信をサポートすることができます。このような拡張ヘッダーは、セクション2.1で定義されています。
The following description of the ROUTE sender operation on the mapping of the Application Object to the ROUTE packet payloads logically represents an extension of RFC 5445 [RFC5445], which in turn inherits the context, language, declarations, and restrictions of the FEC building block in RFC 5052 [RFC5052].
ルートパケットペイロードへのアプリケーションオブジェクトのマッピングに関するルート送信者操作の以下の説明は、RFC 5445 [RFC5445]の拡張を表し、FECビルディングブロックのコンテキスト、言語、宣言、および制限を継承します。RFC 5052 [RFC5052]。
The data carried in the payload of a given ROUTE packet constitutes a contiguous portion of the Application Object. ROUTE source delivery can be considered as a special case of the use of the Compact No-Code Scheme associated with FEC Encoding ID = 0 according to Sections 3.4.1 and 3.4.2 of [RFC5445], in which the encoding symbol size is exactly one byte. As specified in Section 2.1, for ROUTE Source Flows, the FEC Payload ID SHALL deliver the 32-bit start_offset. All receivers are expected to support, at minimum, operation with this special case of the Compact No-Code FEC.
特定のルートパケットのペイロードに含まれるデータは、アプリケーションオブジェクトの隣接する部分を構成します。ルートソース配信は、[RFC5445]のセクション3.4.1および3.4.2に従って、FECをエンコードID = 0に関連付けたコンパクトノーコードスキームの使用の特殊なケースと見なすことができます。1つのバイト。セクション2.1で指定されているように、ルートソースフローの場合、FECペイロードIDは32ビットstart_offsetを配信するものとします。すべてのレシーバーは、コンパクトなノーコードFECのこの特別なケースで、少なくとも操作をサポートすることが期待されています。
Note that in the event the source object size is greater than 2^32 bytes (approximately 4.3 GB), the applications (in the broadcaster server and the receiver) are expected to perform segmentation/ reassembly using methods beyond the scope of this document.
ソースオブジェクトサイズが2^32バイト（約4.3 GB）を超える場合、アプリケーション（放送局サーバーとレシーバー）は、このドキュメントの範囲を超えたメソッドを使用してセグメンテーション/再組み立てを実行することが期待されています。
Finally, in some special cases, a ROUTE sender MAY need to produce ROUTE packets that do not contain any payload. This may be required, for example, to signal the end of a session. These dataless packets do not contain FEC Payload ID or payload data, but only the LCT header fields. The total datagram length, conveyed by outer protocol headers (e.g., the IP or UDP header), enables receivers to detect the absence of the LCT header, FEC Payload ID, and payload data.
最後に、いくつかの特別な場合、ルート送信者は、ペイロードを含まないルートパケットを生成する必要がある場合があります。これは、たとえば、セッションの終了を通知するために必要になる場合があります。これらのデータレスパケットには、FECペイロードIDまたはペイロードデータは含まれていませんが、LCTヘッダーフィールドのみが含まれています。外側のプロトコルヘッダー（例：IPまたはUDPヘッダー）によって伝達される総データグラムの長さにより、レシーバーはLCTヘッダー、FECペイロードID、およびペイロードデータの不在を検出できます。
In the basic operation, it is assumed that the Application Object is fully available at the ROUTE sender.
基本操作では、アプリケーションオブジェクトがルート送信者で完全に利用可能であると想定されています。
1. The amount of data to be sent in a single ROUTE packet is limited by the maximum transfer unit of the data packets or the size of the remaining data of the Application Object being sent, whichever is smaller. The transfer unit is determined either by knowledge of underlying transport block sizes or by other constraints.
1. 単一のルートパケットで送信されるデータの量は、データパケットの最大転送単位または送信されるアプリケーションオブジェクトの残りのデータのサイズによって制限されます。転送ユニットは、基礎となる輸送ブロックサイズの知識または他の制約によって決定されます。
2. The start_offset field in the LCT header of the ROUTE packet indicates the byte offset of the carried data in the Application Object being sent.
2. ルートパケットのLCTヘッダーのstart_offsetフィールドは、送信されているアプリケーションオブジェクトのキャリーデータのバイトオフセットを示します。
3. The Close Object flag (B) is set to 1 if this is the last ROUTE packet carrying the data of the Application Object.
3. これがアプリケーションオブジェクトのデータを運ぶ最後のルートパケットである場合、クローズオブジェクトフラグ（b）は1に設定されます。
The order of packet delivery is arbitrary, but in the absence of other constraints, delivery with increasing start_offset value is recommended.
パケット配信の順序はarbitrary意的ですが、他の制約がない場合は、start_offset値が増加するとの配信が推奨されます。
The following additional guidelines should be followed for ROUTE packetization of CMAF Chunked Content in addition to the guidelines of Section 5.2.1:
セクション5.2.1のガイドラインに加えて、CMAFチャンクコンテンツのルートパケット化については、次の追加ガイドラインに従う必要があります。
1. If it is the first ROUTE packet carrying a CMAF Random Access chunk, except for the first CMAF Chunk in the segment, the Codepoint value MAY be set to 10, as specified in the Codepoint value table in Section 2.1. The receiver MAY use this information for optimization of random access.
1. セグメントの最初のCMAFチャンクを除き、CMAFランダムアクセスチャンクを運ぶ最初のルートパケットである場合、セクション2.1のコードポイント値表で指定されているように、コードポイント値を10に設定できます。受信者は、この情報を使用してランダムアクセスを最適化することができます。
2. As soon as the total length of the media object is known, potentially with the packaging of the last CMAF Chunk of a segment, the EXT_TOL extension header MAY be added to the LCT header to signal the Transfer Length, so that the receiver may know this information in a timely fashion.
2. メディアオブジェクトの全長がわかったら、潜在的にセグメントの最後のCMAFチャンクのパッケージングとともに、ext_tol拡張ヘッダーをLCTヘッダーに追加して転送長を信号することができるため、受信機はこれを知ることができますタイムリーな情報。
The sender SHALL use the timing information provided by the application to time the emission of packets for a timely reception. This information may be contained in the Application Objects e.g., DASH segments and/or the presentation manifest. Hence, such packets of streaming media with real-time constraints SHALL be sent in such a way as to enable their timely reception with respect to the presentation timeline.
送信者は、アプリケーションによって提供されるタイミング情報を使用して、タイムリーなレセプションのためにパケットの排出を計算するために使用するものとします。この情報は、アプリケーションオブジェクト、たとえばダッシュセグメントやプレゼンテーションマニフェストに含まれる場合があります。したがって、リアルタイムの制約を備えたストリーミングメディアのパケットは、プレゼンテーションのタイムラインに関してタイムリーな受信を可能にするような方法で送信するものとします。
For File Mode sending:
ファイルモード送信の場合：
* The TOI field in the ROUTE packet header SHALL be set such that Content-Location can be derived at the receiver according to File Template substitution specified in Section 6.3.1.
* ルートパケットヘッダーのTOIフィールドは、セクション6.3.1で指定されたファイルテンプレート置換に従って、コンテンツロケーションを受信機で導出できるように設定するものとします。
* After sending the first packet with a given TOI value, none of the packets pertaining to this TOI SHALL be sent later than the wall clock time as derived from maxExpiresDelta. The EXT_TIME header with Expected Residual Time (ERT) MAY be used in order to convey more accurate expiry time.
* 特定のTOI値で最初のパケットを送信した後、このTOIに関連するパケットは、maxexpiresdeltaから派生した壁の時計時間よりも遅く送信されません。より正確な有効期限を伝えるために、予想残留時間（ERT）を備えたExt_timeヘッダーを使用できます。
The FEC framework uses concepts of the FECFRAME work as defined in RFC 6363 [RFC6363], as well as the FEC building block, RFC 5052 [RFC5052], which is adopted in the existing FLUTE/ALC/LCT specifications.
FECフレームワークは、RFC 6363 [RFC6363]で定義されているFecFrameワークの概念と、FECビルディングブロック、RFC 5052 [RFC5052]を使用します。
The FEC design adheres to the following principles:
FECデザインは、次の原則に準拠しています。
* FEC-related information is provided only where needed.
* FEC関連情報は、必要な場合にのみ提供されます。
* Receivers not capable of this framework can ignore repair packets.
* このフレームワークができない受信機は、修理パケットを無視できます。
* The FEC is symbol based with fixed symbol size per protected Source Flow. The ALC protocol and existing FEC schemes are reused.
* FECは、保護されたソースフローごとに固定記号サイズを持つシンボルに基づいています。ALCプロトコルと既存のFECスキームが再利用されます。
* A FEC Repair Flow provides protection of delivery objects from one or more Source Flows.
* FEC修復フローは、1つ以上のソースフローからの配信オブジェクトの保護を提供します。
The FEC-specific components of the FEC framework are:
FECフレームワークのFEC固有のコンポーネントは次のとおりです。
* FEC Repair Flow declaration including all FEC-specific information.
* すべてのFEC固有の情報を含むFEC修復フロー宣言。
* A FEC transport object that is the concatenation of a delivery object, padding octets, and size information in order to form a chunk of data that has a size in symbols of N, where N >= 1.
* nのシンボルにサイズを持つデータの塊を形成するために、配信オブジェクト、パディングオクテット、およびサイズ情報の連結であるFEC輸送オブジェクト。
* A FEC super-object that is the concatenation of one or more FEC transport objects in order to bundle FEC transport objects for FEC protection.
* FEC保護のためにFECトランスポートオブジェクトをバンドルするために、1つ以上のFECトランスポートオブジェクトの連結であるFECスーパーオブジェクト。
* A FEC protocol and packet structure.
* FECプロトコルとパケット構造。
A receiver needs to be able to recover delivery objects from repair packets based on available FEC information.
受信者は、利用可能なFEC情報に基づいて、修理パケットから配信オブジェクトを回復できる必要があります。
In order to identify a delivery object in the context of the repair protocol, the following information is needed:
修理プロトコルのコンテキストで配信オブジェクトを識別するには、次の情報が必要です。
* TSI and TOI of the delivery object. In this case, the FEC object corresponds to the (entire) delivery object.
* 配信オブジェクトのTSIとTOI。この場合、FECオブジェクトは（全体の）配信オブジェクトに対応します。
* Octet range of the delivery object, i.e., start offset within the delivery object and number of subsequent and contiguous octets of delivery object that constitutes the FEC object (i.e., the FEC-protected portion of the source object). In this case, the FEC object corresponds to a contiguous byte range portion of the delivery object.
* 配信オブジェクトのオクテット範囲、つまり、配信オブジェクト内のオフセットを開始し、FECオブジェクト（つまり、ソースオブジェクトのFEC保護部分）を構成する送達オブジェクトの後続および連続的なオクテットの数を開始します。この場合、FECオブジェクトは、配信オブジェクトの連続バイト範囲部分に対応します。
Typically, for real-time object delivery with smaller delivery object sizes, the first mapping is applied, i.e., the delivery object is a FEC object.
通常、配信オブジェクトサイズが小さいリアルタイムオブジェクト配信の場合、最初のマッピングが適用されます。つまり、配信オブジェクトはFECオブジェクトです。
Assuming that the FEC object is the delivery object, for each delivery object, the associated FEC transport object is comprised of the concatenation of the delivery object, padding octets (P), and the FEC object size (F) in octets, where F is carried in a 4-octet field.
FECオブジェクトが配信オブジェクトであると仮定すると、各配信オブジェクトの場合、関連するFECトランスポートオブジェクトは、配信オブジェクトの連結、パディングオクテット（P）、およびオクテットのFECオブジェクトサイズ（F）で構成されています。4オクテットのフィールドで運ばれます。
The FEC transport object size S, in FEC encoding symbols, SHALL be an integer multiple of the symbol size Y. S is determined from the session information and/or the repair packet headers.
FECエンコードシンボルのFECトランスポートオブジェクトサイズsは、シンボルサイズYの整数倍でなければなりません。Sは、セッション情報および/または修理パケットヘッダーから決定されます。
F is carried in the last 4 octets of the FEC transport object. Specifically, let:
Fは、FEC輸送オブジェクトの最後の4オクテットに運ばれます。具体的には、
* F be the size of the delivery object in octets,
* fオクテットの配信オブジェクトのサイズ、
* F' be the F octets of data of the delivery object,
* f '配信オブジェクトのデータのfオクテット、
* f' denote the four octets of data carrying the value of F in network octet order (high-order octet first),
* f 'は、ネットワークオクテットの順序でfの値を運ぶ4つのデータの4オクテットを示します（最初に高次のオクテット）、
* S be the size of the FEC transport object with S=ceil((F+4)/Y), where the ceil() function rounds the result upward to its nearest integer,
* s s = ceil（（f 4）/y）を備えたFECトランスポートオブジェクトのサイズであり、ceil（）関数は結果を最寄りの整数まで上方に回ります。
* P' be S*Y-4-F octets of data, i.e., padding placed between the delivery object and the 4-byte field conveying the value of F and located at the end of the FEC transport object, and
* p 'be s*y-4-fデータ、すなわち、配信オブジェクトとfの値を伝達し、FEC輸送オブジェクトの端にある4バイトフィールドの間に配置されたパディング、および
* O' be the concatenation of F', P', and f'.
* o 'f'、p '、およびf'の連結。
O' then constitutes the FEC transport object of size S*Y octets. Note that padding octets and the object size F are not sent in source packets of the delivery object but are only part of a FEC transport object that FEC decoding recovers in order to extract the FEC object and thus the delivery object or portion of the delivery object that constitutes the FEC object. In the above context, the FEC transport object size in symbols is S.
o '次に、サイズs*yオクテットのFEC輸送オブジェクトを構成します。パディングオクテットとオブジェクトサイズfは配信オブジェクトのソースパケットで送信されるのではなく、FECオブジェクト、したがって配信オブジェクトの配信オブジェクトまたは一部を抽出するために回復するFEC輸送オブジェクトの一部のみであることに注意してください。それはFECオブジェクトを構成します。上記のコンテキストでは、シンボルのFECトランスポートオブジェクトサイズはSです。
The general information about a FEC transport object that is conveyed to a FEC-enabled receiver is the source TSI, source TOI, and the associated octet range within the delivery object comprising the associated FEC object. However, as the size in octets of the FEC object is provided in the appended field within the FEC transport object, the remaining information can be conveyed as:
FEC対応レシーバーに運ばれるFEC輸送オブジェクトに関する一般的な情報は、ソースTSI、ソースTOI、および関連するFECオブジェクトを含む配信オブジェクト内の関連するオクテット範囲です。ただし、FECオブジェクトのオクテットのサイズがFECトランスポートオブジェクト内のAppledフィールドに提供されるため、残りの情報は次のように伝えることができます。
* The TSI and TOI of the delivery object from which the FEC object associated with the FEC transport object is generated
* FECトランスポートオブジェクトに関連付けられたFECオブジェクトが生成される配信オブジェクトのTSIとTOI
* The start octet within the delivery object for the associated FEC object
* 関連するFECオブジェクトの配信オブジェクト内のスタートオクテット
* The size in symbols of the FEC transport object, S
* FECトランスポートオブジェクトのシンボルのサイズ、s
From the FEC Repair Flow declaration, the construction of a FEC super-object as the concatenation of one or more FEC transport objects can be determined. The FEC super-object includes the general information about the FEC transport objects as described in the previous sections, as well as the placement order of FEC transport objects within the FEC super-object.
FEC修復フロー宣言から、1つまたは複数のFEC輸送オブジェクトの連結としてのFECスーパーオブジェクトの構築を決定できます。FEC Super-Objectには、前のセクションで説明されているFEC輸送オブジェクトに関する一般的な情報と、FEC Super-Object内のFECトランスポートオブジェクトの配置順序が含まれています。
Let:
させて：
* N be the total number of FEC transport objects for the FEC super-object construction.
* n FECスーパーオブジェクト構造のFEC輸送オブジェクトの総数。
* For i = 0, ..., N-1, let S[i] be the size in symbols of FEC transport object i.
* i = 0、...、n-1の場合、S [i]をFEC輸送オブジェクトのシンボルのサイズとします。
* B' be the FEC super-object that is the concatenation of the FEC transport objects in numerical order, comprised of K = Sum of N source symbols, each symbol denoted as S[i].
* b 'は、s [i]として示される各シンボルのk = sソース記号のk = sumで構成された数値順序でFECトランスポートオブジェクトの連結であるFECスーパーオブジェクトです。
For each FEC super-object, the remaining general information that needs to be conveyed to a FEC-enabled receiver, beyond what is already carried in the FEC transport objects that constitute the FEC super-object, comprises:
FECスーパーオブジェクトごとに、FECスーパーオブジェクトを構成するFECトランスポートオブジェクトに既に運ばれているものを超えて、FEC対応レシーバーに伝える必要がある残りの一般情報は次のとおりです。
* The total number of FEC transport objects N.
* FEC輸送オブジェクトの総数n。
* For each FEC transport object:
* 各FECトランスポートオブジェクトについて：
- The TSI and TOI of the delivery object from which the FEC object associated with the FEC transport object is generated,
- FECトランスポートオブジェクトに関連付けられたFECオブジェクトが生成される配信オブジェクトのTSIとTOI、
- The start octet within the delivery object for the associated FEC object, and
- 関連するFECオブジェクトの配信オブジェクト内のスタートオクテット、および
- The size in symbols of the FEC transport object.
- FECトランスポートオブジェクトのシンボルのサイズ。
The carriage of the FEC repair information is discussed below.
FEC修理情報のキャリッジについては、以下で説明します。
The repair protocol is based on Asynchronous Layered Coding (ALC) as defined in RFC 5775 [RFC5775] and the Layered Coding Transport (LCT) Building Block as defined in RFC 5651 [RFC5651] with the following details:
修復プロトコルは、RFC 5775 [RFC5775]で定義されている非同期層コーディング（ALC）と、RFC 5651 [RFC5651]で定義されている層状コーディング輸送（LCT）ビルディングブロックに基づいています。
* The Layered Coding Transport (LCT) Building Block as defined in RFC 5651 [RFC5651] is used as defined in Asynchronous Layered Coding (ALC), Section 2.1. In addition, the following constraint applies:
* RFC 5651 [RFC5651]で定義されている層状コーディング輸送（LCT）ビルディングブロックは、非同期層コード（ALC）、セクション2.1で定義されています。さらに、次の制約が適用されます。
- The TSI in the LCT header SHALL identify the Repair Flow to which this packet applies by the matching the value of the ptsi attribute in the signaling metadata among the LCT channels carrying Repair Flows.
- LCTヘッダーのTSIは、修理フローを運ぶLCTチャネルのシグナリングメタデータのPTSI属性の値を一致させることにより、このパケットが適用される修復フローを特定するものとします。
* The FEC building block is used according to RFC 6330 [RFC6330], but only repair packets are delivered.
* FECビルディングブロックは、RFC 6330 [RFC6330]に従って使用されますが、修理パケットのみが配信されます。
- Each repair packet within the scope of the Repair Flow (as indicated by the TSI field in the LCT header) SHALL carry the repair symbols for a corresponding FEC transport object/super-object as identified by its TOI. The repair object/super-object TOI SHALL be unique for each FEC super-object that is created within the scope of the TSI.
- 修復フローの範囲内の各修理パケット（LCTヘッダーのTSIフィールドで示されているように）は、TOIで識別されるように、対応するFECトランスポートオブジェクト/スーパーオブジェクトの修理記号を運ぶものとします。修理オブジェクト/スーパーオブジェクトTOIは、TSIの範囲内で作成されるFECスーパーオブジェクトごとに一意でなければなりません。
For each super-object (identified by a unique TOI within a Repair Flow that is in turn identified by the TSI in the LCT header) that is generated, the following information needs to be communicated to the receiver:
生成された各スーパーオブジェクト（修復フロー内の一意のTOIによって識別されます）について、次の情報を受信機に伝える必要があります。
* The FEC configuration consisting of:
* 以下で構成されるFEC構成
- FEC Object Transmission Information (OTI) per RFC 5052 [RFC5052].
- RFC 5052 [RFC5052]あたりのFECオブジェクトトランスミッション情報（OTI）。
- Additional FEC information (see Section 3.3).
- 追加のFEC情報（セクション3.3を参照）。
- The total number of FEC objects included in the FEC super-object, N.
- FEC Super-Object、N。に含まれるFECオブジェクトの総数。
* For each FEC transport object:
* 各FECトランスポートオブジェクトについて：
- TSI and TOI of the delivery object used to generate the FEC object associated with the FEC transport object,
- FECトランスポートオブジェクトに関連付けられたFECオブジェクトを生成するために使用される配信オブジェクトのTSIとTOI、
- The start octet within the delivery object of the associated FEC object, if applicable, and
- 関連するFECオブジェクトの配信オブジェクト内のスタートオクテット、該当する場合は、
- The size in symbols of the FEC transport object, S.
- FECトランスポートオブジェクトのシンボルのサイズ、S。
The above information is delivered:
上記の情報が配信されます。
* Statically in the session metadata as defined in Section 3.3, and
* セクション3.3で定義されているように、セッションメタデータで静的に、および
* Dynamically in an LCT extension header.
* LCT拡張ヘッダーで動的に。
The receiver receives packets and filters those packets according to the following. From the ROUTE session and each contained LCT channel, the receiver regenerates delivery objects from the ROUTE session and each contained LCT channel.
受信機は、次のパケットを受信し、それらのパケットをフィルターします。ルートセッションとそれぞれにLCTチャネルが含まれていることから、受信機はルートセッションから配信オブジェクトを再生し、それぞれにLCTチャネルが含まれていました。
In the event that the receiver receives data that does not conform to the ROUTE protocol specified in this document, the receiver SHOULD attempt to recover gracefully by e.g., informing the application about the issues using means beyond the scope of this document. The ROUTE packetization specified in Section 5.2.1 implies that the receiver SHALL NOT receive overlapping data; if such a condition is encountered at the receiver, the packet SHALL be assumed to be corrupted.
受信機がこのドキュメントで指定されたルートプロトコルに準拠していないデータを受信した場合、レシーバーは、このドキュメントの範囲を超えた平均を使用して問題についてアプリケーションに通知することにより、優雅に回復しようとする必要があります。セクション5.2.1で指定されたルートパケット化は、受信機が重複したデータを受け取ってはならないことを意味します。そのような条件が受信機で遭遇した場合、パケットは破損していると想定されます。
The basic receiver operation is provided below (it assumes an error-free scenario), while repair considerations are provided in Section 7.
基本的な受信機操作は以下に示されています（エラーのないシナリオを想定しています）。一方、修理の考慮事項はセクション7で提供されます。
Upon receipt of each ROUTE packet of a Source Flow, the receiver proceeds with the following steps in the order listed.
ソースフローの各ルートパケットを受け取ると、レシーバーは、リストされた順序で次の手順を進めます。
1) The ROUTE receiver is expected to parse the LCT and FEC Payload ID to verify that it is a valid header. If it is not valid, then the payload is discarded without further processing.
1) ルートレシーバーは、LCTおよびFECペイロードIDを解析して、有効なヘッダーであることを確認することが期待されています。有効でない場合、ペイロードはさらに処理せずに破棄されます。
2) All ROUTE packets used to recover a specific delivery object carry the same TOI value in the LCT header.
2) 特定の配信オブジェクトを回復するために使用されるすべてのルートパケットは、LCTヘッダーに同じTOI値を運びます。
3) The ROUTE receiver is expected to assert that the TSI and the Codepoint represent valid operation points in the signaling metadata, i.e., the signaling contains a matching entry to the TSI value provided in the packet header, as well as for this TSI, and the Codepoint field in the LCT header has a valid Codepoint mapping.
3) ルートレシーバーは、TSIとCodePointがシグナルメタデータの有効な動作ポイントを表していることを主張することが期待されています。つまり、シグナリングには、パケットヘッダーに提供されるTSI値、およびこのTSI、およびCODEPOINTの一致するエントリが含まれています。LCTヘッダーのフィールドには、有効なCodePointマッピングがあります。
4) The ROUTE receiver should process the remainder of the payload, including the appropriate interpretation of the other payload header fields, using the source FEC Payload ID (to determine the start_offset) and the payload data to reconstruct the corresponding object as follows:
4) ルートレシーバーは、ソースFECペイロードID（start_offsetを決定するために）とペイロードデータを使用して、次のように対応するオブジェクトを再構築するために、他のペイロードヘッダーフィールドの適切な解釈を含む、ペイロードの残りを処理する必要があります。
a. For File Mode, upon receipt of the first ROUTE packet payload for an object, the ROUTE receiver uses the File@Transfer-Length attribute of the associated Extended FDT-Instance, when present, to determine the length T of the object. When the File@Transfer-Length attribute is not present in the Extended FDT-Instance, the receiver uses the maxTransportSize attribute of the associated Extended FDT-Instance to determine the maximum length T' of the object. Alternatively, and specifically for delivery modes other than File Mode, the EXT_TOL header can be used to determine the length T of the object.
a. ファイルモードの場合、オブジェクトの最初のルートパケットペイロードを受信すると、ルートレシーバーは、存在する場合、関連する拡張FDTインスタンスのファイル@転送長属性を使用して、オブジェクトの長さtを決定します。File@Transfer-Length属性が拡張FDTインスタンスに存在しない場合、受信者は、関連する拡張FDTインスタンスのMaxTransportsize属性を使用して、オブジェクトの最大長t 'を決定します。または、特にファイルモード以外の配信モード用に特に、ext_tolヘッダーを使用してオブジェクトの長さtを決定できます。
b. The ROUTE receiver allocates buffer space for the T or T' bytes that the object will or may occupy.
b. ルートレシーバーは、オブジェクトが占有するか、T 'バッテまたはT'バッファースペースを割り当てます。
c. The ROUTE receiver computes the length of the payload, Y, by subtracting the payload header length from the total length of the received payload.
c. ルートレシーバーは、受信したペイロードの全長からペイロードヘッダーの長さを差し引くことにより、ペイロードの長さを計算します。
d. The ROUTE receiver allocates a Boolean array RECEIVED[0..T-1] or RECEIVED[0..T'-1], as appropriate, with all entries initialized to false to track received object symbols. The ROUTE receiver continuously acquires packet payloads for the object as long as all of the following conditions are satisfied:
d. ルートレシーバーは、受信した[0..t-1]または受信した[0..t'-1]を受信したブールアレイを割り当てます。ルートレシーバーは、次のすべての条件が満たされている限り、オブジェクトのパケットペイロードを継続的に取得します。
i. there is at least one entry in RECEIVED still set to false,
i. 受信したエントリは、まだfalseに設定されています。
ii. the object has not yet expired, and
ii。オブジェクトはまだ期限切れになっていません
iii. the application has not given up on reception of this object.
iii。アプリケーションは、このオブジェクトの受信をあきらめていません。
More details are provided below.
詳細を以下に示します。
e. For each received ROUTE packet payload for the object (including the first payload), the steps to be taken to help recover the object are as follows:
e. オブジェクトの受信ルートパケットペイロード（最初のペイロードを含む）について、オブジェクトを回復するのに役立つ手順は次のとおりです。
i. If the packet includes an EXT_TOL or EXT_FTI header, modify the Boolean array RECEIVED[0..T'-1] to become RECEIVED[0..T-1].
i. パケットにext_tolまたはext_ftiヘッダーが含まれている場合、受信した[0..t'-1]を受信したブールアレイを変更して受信します[0..t-1]。
ii. Let X be the value of the start_offset field in the ROUTE packet header and let Y be the length of the payload, Y, computed by subtracting the LCT header size and the FEC Payload ID size from the total length of the received packet.
ii。xをルートパケットヘッダーのstart_offsetフィールドの値とし、yをペイロードの長さ、yとし、LCTヘッダーサイズとFECペイロードIDサイズを受信パケットの全長から減算することにより計算します。
iii. The ROUTE receiver copies the data into the appropriate place within the space reserved for the object and sets RECEIVED[X ... X+Y-1] = true.
iii。ルートレシーバーは、データをオブジェクトのために予約されたスペース内の適切な場所にコピーし、受信した[x ... x y-1] = true。
iv. If all T entries of RECEIVED are true, then the receiver has recovered the entire object.
IV。受信したすべてのエントリが真である場合、受信者はオブジェクト全体を回復しました。
Upon recovery of both the complete set of packet payloads for the delivery object associated with a given TOI value, and the metadata for that delivery object, the reception of the delivery object, now a fully received Application Object, is complete.
特定のTOI値に関連付けられた配信オブジェクトのパケットペイロードの完全なセットと、その配信オブジェクトのメタデータは、現在完全に受信されたアプリケーションオブジェクトである配信オブジェクトの受信の両方を回復すると、完全になりました。
Given the timely reception of ROUTE packets belonging to an Application Object, the receiver SHALL make the Application Objects available to the application in a timely fashion using the application-provided timing data (e.g., the timing data signaled via the presentation manifest file). For example, HTTP/1.1 chunked transfer may need to be enabled to transfer the Application Objects if MPD@availabilityTimeOffset is signaled in the DASH presentation manifest in order to allow for the timely sending of segment data to the application.
アプリケーションオブジェクトに属するルートパケットのタイムリーな受信を考えると、受信者は、アプリケーションが提供するタイミングデータ（例：プレゼンテーションマニフェストファイルを介してシグナルにされたタイミングデータ）を使用して、アプリケーションオブジェクトをアプリケーションでタイムリーに利用できるようにするものとします。たとえば、MPD@availabilityTimeOffsetがアプリケーションにタイムリーにセグメントデータを送信することを可能にするために、DASHプレゼンテーションマニフェストで信号が表示される場合、HTTP/1.1チャンク転送をアプリケーションオブジェクトを転送するために有効にする必要がある場合があります。
When the receiver initially starts reception of ROUTE packets, it is likely that the reception does not start from the very first packet carrying the data of a multicast transport object; in this case, such a partially received object is normally discarded. However, the channel acquisition or "tune-in" times can be improved if the partially received object is usable by the application. One example realization for this is as follows:
受信者が最初にルートパケットの受信を開始すると、マルチキャストトランスポートオブジェクトのデータを運ぶ最初のパケットから受信が開始されない可能性があります。この場合、そのような部分的に受信されたオブジェクトは通常破棄されます。ただし、部分的に受信したオブジェクトがアプリケーションによって使用可能である場合、チャネルの取得または「チューニング」時間を改善することができます。これの1つの例は次のとおりです。
* The receiver checks for the first received packet with the Codepoint value set to 10, indicating the start of a CMAF Random Access chunk.
* 受信者は、CODEPOINT値が10に設定された最初の受信パケットをチェックし、CMAFランダムアクセスチャンクの開始を示します。
* The receiver MAY make the partially received object (a partial DASH segment starting from the packet above) available to the application for fast stream acquisition.
* 受信者は、部分的に受信したオブジェクト（上記のパケットから始まる部分的なダッシュセグメント）を、高速ストリーム取得のためにアプリケーションで利用できるようにすることができます。
* It MAY recover the earliest presentation time of this CMAF Random Access chunk from the ROUTE packet LCT Congestion Control Information (CCI) field as specified in Section 2.1 to be able to add a new Period element in the MPD exposed to the application containing just the partially received DASH segment with period continuity signaling.
* セクション2.1で指定されているルートパケットlct混雑制御情報（CCI）フィールドからこのCMAFランダムアクセスチャンクの最も早いプレゼンテーション時間を回復する場合があります。周期連続性シグナル伝達を備えたダッシュセグメントを受信しました。
An Extended FDT-Instance conforming to RFC 6726 [RFC6726], is produced at the receiver using the service metadata and in-band signaling in the following steps:
RFC 6726 [RFC6726]に適合する拡張FDTインスタンスは、以下のステップでサービスメタデータとインバンドシグナル伝達を使用して受信機で生成されます。
The Content-Location element of the Extended FDT for a specific Application Object is derived as follows:
特定のアプリケーションオブジェクトの拡張FDTのコンテンツロケーション要素は、次のように導出されます。
"$TOI$" is substituted with the unique TOI value in the LCT header of the ROUTE packets used to recover the given delivery object (as specified in Section 6.1).
「$ toi $」は、指定された配信オブジェクトを回復するために使用されるルートパケットのLCTヘッダーの一意のTOI値に置き換えられます（セクション6.1で指定されています）。
After the substitution, the fileTemplate SHALL be a valid URL corresponding to the Content-Location attribute of the associated Application Object.
置換後、FileTemplateは、関連するアプリケーションオブジェクトのコンテンツロケーション属性に対応する有効なURLでなければなりません。
An example @fileTemplate using a width of 5 is: fileTemplate="myVideo$TOI%05d$.mps", resulting in file names with exactly five digits in the number portion. The Media Segment file name for TOI=33 using this template is myVideo00033.mps.
5の幅を使用した@FileTemplateの例は、FileTemplate = "myVideo $ toi％05d $ .mps"で、数値部分にちょうど5桁のファイル名が得られます。TOI = 33のメディアセグメントファイル名は、このテンプレートを使用しています。MyVideo00033.MPSです。
Either the EXT_FTI header (per RFC 5775 [RFC5775]) or the EXT_TOL header, when present, is used to derive the Transport Object Length (TOL) of the File. If the File@Transfer-Length parameter in the Extended FDT-Instance is not present, then the EXT_TOL header or the or EXT_FTI header SHALL be present. Note that a header containing the transport object length (EXT_TOL or EXT_FTI) need not be present in each packet header. If the broadcaster does not know the length of the transport object at the beginning of the transfer, an EXT_TOL or EXT_FTI header SHALL be included in at least the last packet of the file and should be included in the last few packets of the transfer.
ext_ftiヘッダー（RFC 5775 [RFC5775]ごと）またはext_tolヘッダーは、存在する場合、ファイルのトランスポートオブジェクト長（TOL）を導出するために使用されます。拡張FDTインスタンスのファイル@転送長パラメーターが存在しない場合、ext_tolヘッダーまたはまたはext_ftiヘッダーが存在するものとします。トランスポートオブジェクトの長さ（ext_tolまたはext_fti）を含むヘッダーは、各パケットヘッダーに存在する必要はないことに注意してください。放送局が転送開始時にトランスポートオブジェクトの長さを知らない場合、ext_tolまたはext_ftiヘッダーは少なくともファイルの最後のパケットに含まれ、転送の最後の数パケットに含める必要があります。
When present, the maxExpiresDelta attribute SHALL be used to generate the value of the FDT-Instance@Expires attribute. The receiver is expected to add this value to its wall clock time when acquiring the first ROUTE packet carrying the data of a given delivery object to obtain the value for @Expires.
存在する場合、maxexpiresdelta属性を使用して、fdt-instance@expires属性の値を生成するものとします。受信機は、特定の配信オブジェクトのデータを運ぶ最初のルートパケットを取得して @Expiresの値を取得するときに、この値を壁の時計時間に追加することが期待されます。
When maxExpiresDelta is not present, the EXT_TIME header with Expected Residual Time (ERT) SHALL be used to derive the expiry time of the Extended FDT-Instance. When both maxExpiresDelta and the ERT of EXT_TIME are present, the smaller of the two values should be used as the incremental time interval to be added to the receiver's current time to generate the effective value for @Expires. When neither maxExpiresDelta nor the ERT field of the EXT_TIME header is present, then the expiration time of the Extended FDT-Instance is given by its @Expires attribute.
maxexpiresdeltaが存在しない場合、予想される残差時間（ERT）を持つext_timeヘッダーを使用して、拡張FDTインスタンスの有効期限を導出するものとします。maxexpiresdeltaとext_timeのERTの両方が存在する場合、2つの値のうち少ない値を、 @Expiresの有効値を生成するために、受信者の現在の時間に追加される増分時間間隔として使用する必要があります。maxexpiresdeltaもext_timeヘッダーのERTフィールドも存在しない場合、拡張FDTインスタンスの有効期限は@expires属性によって与えられます。
It is up to the receiver to decide to use zero, one, or more of the FEC streams. Hence, the application assigns a recovery property to each flow, which defines aspects such as the delay and the required memory if one or the other is chosen. The receiver MAY decide whether or not to utilize Repair Flows based on the following considerations:
FECストリームのゼロ、1つ、またはそれ以上を使用することを決定するのはレシーバー次第です。したがって、アプリケーションは各フローに回復プロパティを割り当てます。これは、どちらか一方が選択されている場合に遅延や必要なメモリなどの側面を定義します。受信者は、次の考慮事項に基づいて修理フローを利用するかどうかを決定できます。
* The desired start-up and end-to-end latency. If a Repair Flow requires a significant amount of buffering time to be effective, such Repair Flow might only be used in time-shift operations or in poor reception conditions, since use of such Repair Flow trades off end-to-end latency against DASH Media Presentation quality.
* 目的の起動とエンドツーエンドのレイテンシ。修理フローで効果的になるためにかなりの量のバッファリング時間が必要な場合、そのような修理フローの使用はダッシュメディアに対するエンドツーエンドのレイテンシを使用するため、タイムシフト操作または受信条件の低下でのみ使用される可能性があります。プレゼンテーション品質。
* FEC capabilities, i.e., the receiver MAY pick only the FEC algorithm that it supports.
* FEC機能、つまり、レシーバーは、サポートするFECアルゴリズムのみを選択できます。
* Which Source Flows are being protected; for example, if the Repair Flow protects Source Flows that are not selected by the receiver, then the receiver may not select the Repair Flow.
* どのソースフローが保護されているか。たとえば、修復フローが受信機によって選択されていないソースフローを保護する場合、受信機は修復フローを選択できない場合があります。
* Other considerations such as available buffer size, reception conditions, etc.
* 利用可能なバッファサイズ、受信条件など、その他の考慮事項。
If a receiver decides to acquire a certain Repair Flow, then the receiver must receive data on all Source Flows that are protected by that Repair Flow to collect the relevant packets.
受信者が特定の修理フローを取得することを決定した場合、受信者は、その修理フローによって保護されているすべてのソースフローに関するデータを受け取って、関連するパケットを収集する必要があります。
When mappingTOIx/mappingTOIy are used to signal X and Y values, the TOI value(s) of the one or more source objects (sourceTOI) protected by a given FEC transport object or FEC super-object with a TOI value rTOI is derived through an equation sourceTOI = X*rTOI + Y.
MappingToix/MappingToiyを使用してXとYの値を信号にする場合、特定のFECトランスポートオブジェクトまたはFECスーパーオブジェクトによって保護されている1つ以上のソースオブジェクト（sourcetoi）のtoi値は、rtoiを介して導出されます。方程式sourcetoi = x*rtoi y。
When neither mappingTOIx nor mappingTOIy is present, there is a 1:1 relationship between each delivery object carried in the Source Flow as identified by ptsi to a FEC object carried in this Repair Flow. In this case, the TOI of each of those delivery objects SHALL be identical to the TOI of the corresponding FEC object.
MappingToixもMappingToiyも存在しない場合、PTSIによってこの修理フローで運ばれるFECオブジェクトに識別されるように、ソースフローに運ばれる各配信オブジェクトの間に1：1の関係があります。この場合、それらの各配信オブジェクトのTOIは、対応するFECオブジェクトのTOIと同一でなければなりません。
The permitted start and end times for the receiver to perform the file repair procedure, in case of unsuccessful broadcast file reception, and associated rules and parameters are as follows:
ブロードキャストファイルの受信が失敗した場合、受信者がファイル修理手順を実行するための許可された開始時間と終了時間、および関連するルールとパラメーターは次のとおりです。
* The latest time that the file repair procedure may start is bound by the @Expires attribute of the FDT-Instance.
* ファイルの修理手順が開始される可能性のある最新の時間は、FDTインスタンスの@expires属性に拘束されます。
* The receiver may choose to start the file repair procedure earlier if it detects the occurrence of any of the following events:
* 受信者は、次のイベントのいずれかの発生を検出した場合、ファイルの修理手順を早期に開始することを選択できます。
- Presence of the Close Object flag (B) in the LCT header [RFC5651] for the file of interest;
- 関心のあるファイルのためのLCTヘッダー[RFC5651]に近接オブジェクトフラグ（b）の存在。
- Presence of the Close Session flag (A) in the LCT header [RFC5651] before the nominal expiration of the Extended FDT-Instance as defined by the @Expires attribute.
- @Expires属性によって定義されている拡張FDTインスタンスの公称有効期限の前に、LCTヘッダー[RFC5651]に近接セッションフラグ（a）の存在。
To be able to recover the delivery objects that are protected by a Repair Flow, a receiver needs to obtain the necessary Service signaling metadata fragments that describe the corresponding collection of delivery objects that are covered by this Repair Flow. A Repair Flow is characterized by the combination of an LCT channel, a unique TSI number, as well as the corresponding protected Source Flows.
修理フローによって保護されている配信オブジェクトを回復できるようにするには、受信者は、この修理フローでカバーされている配信オブジェクトの対応するコレクションを説明する必要なサービスシグナリングメタデータフラグメントを取得する必要があります。修復フローは、LCTチャネル、一意のTSI番号、および対応する保護されたソースフローの組み合わせによって特徴付けられます。
If a receiver acquires data of a Repair Flow, the receiver is expected to collect all packets of all protected Transport Sessions. Upon receipt of each packet, whether it is a source or repair packet, the receiver proceeds with the following steps in the order listed.
受信者が修理フローのデータを取得した場合、受信機は保護されたすべての輸送セッションのすべてのパケットを収集することが期待されます。各パケットを受信すると、ソースであろうと修理パケットであろうと、レシーバーは、リストされた順序で次の手順を進めます。
1. The receiver is expected to parse the packet header and verify that it is a valid header. If it is not valid, then the packet SHALL be discarded without further processing.
1. 受信機は、パケットヘッダーを解析し、有効なヘッダーであることを確認することが期待されています。有効でない場合、パケットはさらに処理せずに破棄されます。
2. The receiver is expected to parse the TSI field of the packet header and verify that a matching value exists in the Service signaling for the Repair Flow or the associated Protected Source Flow. If no match is found, the packet SHALL be discarded without further processing.
2. 受信機は、パケットヘッダーのTSIフィールドを解析し、修理フローまたは関連する保護されたソースフローのサービス信号に一致する値が存在することを確認することが期待されています。一致が見つからない場合、パケットはさらに処理せずに破棄されます。
3. The receiver processes the remainder of the packet, including interpretation of the other header fields, and using the source FEC Payload ID (to determine the start_offset byte position within the source object), the Repair FEC Payload ID, as well as the payload data, reconstructs the decoding blocks corresponding to a FEC super-object as follows:
3. レシーバーは、他のヘッダーフィールドの解釈やソースFECペイロードID（ソースオブジェクト内のstart_offsetバイト位置を決定するために）、修理FECペイロードID、およびペイロードデータを使用するなど、パケットの残りを処理します。次のように、FECスーパーオブジェクトに対応するデコードブロックを再構築します。
a. For a source packet, the receiver identifies the delivery object to which the received packet is associated using the session information and the TOI carried in the payload header. Similarly, for a repair object, the receiver identifies the FEC super-object to which the received packet is associated using the session information and the TOI carried in the payload header.
a. ソースパケットの場合、受信者は、受信したパケットがセッション情報を使用して関連付けられている配信オブジェクトを識別し、ペイロードヘッダーに携帯しているTOIを識別します。同様に、修理オブジェクトの場合、受信者は、受信したパケットがセッション情報を使用して関連付けられているFECスーパーオブジェクトとペイロードヘッダーに携帯されているTOIを識別します。
b. For source packets, the receiver collects the data for each FEC super-object and recovers FEC super-objects in the same way as a Source Flow in Section 6.1. The received FEC super-object is then mapped to a source block and the corresponding encoding symbols are generated.
b. ソースパケットの場合、受信機は各FECスーパーオブジェクトのデータを収集し、セクション6.1のソースフローと同じようにFECスーパーオブジェクトを回復します。受信したFECスーパーオブジェクトは、ソースブロックにマッピングされ、対応するエンコードシンボルが生成されます。
c. With the reception of the repair packets, the FEC super-object can be recovered.
c. 修理パケットを受信すると、FECスーパーオブジェクトを回復できます。
d. Once the FEC super-object is recovered, the individual delivery objects can be extracted.
d. FEC Super-Objectが回収されると、個々の配信オブジェクトを抽出できます。
Services (e.g., ATSC-ROUTE [ATSCA331], DVB-MABR [DVBMABR], etc.) may define specific ROUTE "profiles" based on this document in their respective standards organizations. An example is noted in the overview section: DVB has specified a profile of ATSC-ROUTE in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) [DVBMABR]. The definition has the following considerations. Services MAY
サービス（たとえば、ATSC-Route [ATSCA331]、DVB-MABR [DVBMABR]など）は、それぞれの標準組織のこのドキュメントに基づいて特定のルート「プロファイル」を定義する場合があります。例は、概要セクションに記載されています。DVBは、IPマルチキャスト（DVB-MABR）[DVBMABR]を介したDVB適応メディアストリーミングのATSC-Routeのプロファイルを指定しています。定義には次の考慮事項があります。サービスはそうかもしれません
* Restrict the signaling of certain values signaled in the LCT header and/or provision unused fields in the LCT header.
* LCTヘッダーおよび/またはLCTヘッダーの未使用フィールドをプロビジョニングする特定の値のシグナルを制限します。
* Restrict using certain LCT header extensions and/or add new LCT header extensions.
* 特定のLCTヘッダー拡張機能を使用して制限し、新しいLCTヘッダー拡張機能を追加します。
* Restrict or limit usage of some Codepoints and/or assign semantics to service-specific Codepoints marked as reserved in this document.
* いくつかのコードポイントの使用法を制限または制限し、このドキュメントで予約されているとマークされたサービス固有のコードポイントにセマンティクスを割り当てます。
* Restrict usage of certain Service signaling attributes and/or add their own service metadata.
* 特定のサービス信号属性の使用法を制限し、独自のサービスメタデータを追加します。
Services SHALL NOT redefine the semantics of any of the ROUTE attributes in LCT headers and extensions, as well as Service signaling attributes already specified in this document.
サービスは、LCTヘッダーと拡張機能のルート属性のセマンティクス、およびこのドキュメントで既に指定されているサービスシグナル属性を再定義してはなりません。
By following these guidelines, services can define profiles that are interoperable.
これらのガイドラインに従うことにより、サービスは相互運用可能なプロファイルを定義できます。
Different ROUTE delivery modes specified in Section 4 are optimized for delivery of different types of media data. For example, File Mode is specifically optimized for delivering DASH content using Segment Template with number substitution. Using File Template in EFDT avoids the need for the repeated sending of metadata as outlined in the following section. Same optimizations, however, cannot be used for time substitution and segment timeline where the addressing of each segment is time dependent and in general does not follow a fixed or repeated pattern. In this case, Entity Mode is more optimized since it carries the file location in band. Also, Entity Mode can be used to deliver a file or part of the file using HTTP Partial Content response headers.
セクション4で指定されたさまざまなルート配信モードは、さまざまな種類のメディアデータの配信に最適化されています。たとえば、ファイルモードは、数値置換を備えたセグメントテンプレートを使用してダッシュコンテンツを配信するために特別に最適化されています。EFDTでファイルテンプレートを使用すると、次のセクションで概説されているように、メタデータを繰り返し送信する必要がなくなります。ただし、同じ最適化は、各セグメントのアドレス指定が時間に依存し、一般に固定パターンまたは繰り返しパターンに従っていない時間代替およびセグメントタイムラインに使用することはできません。この場合、エンティティモードはバンド内のファイルの場所を運ぶため、より最適化されています。また、エンティティモードを使用して、HTTP Partial Content Responseヘッダーを使用してファイルまたはファイルの一部を配信できます。
In File Mode, the delivery object represents an Application Object. This mode replicates FLUTE as defined in RFC 6726 [RFC6726] but with the ability to send static and pre-known file metadata out of band.
ファイルモードでは、配信オブジェクトはアプリケーションオブジェクトを表します。このモードは、RFC 6726 [RFC6726]で定義されているフルートを複製しますが、静的および事前に知られているファイルメタデータをバンドから送信する機能を備えています。
In FLUTE, FDT-Instances are delivered in band and need to be generated and delivered in real time if objects are generated in real time at the sender. These FDT-Instances have some differences as compared to the FDT specified in Section 3.4.2 of [RFC6726] and Section 7.2.10 of MBMS [MBMS]. The key difference is that besides separated delivery of file metadata from the delivery object it describes, the FDT functionality in ROUTE may be extended by additional file metadata and rules that enable the receiver to generate the Content-Location attribute of the File element of the FDT, on the fly. This is done by using information in both the extensions to the FDT and the LCT header. The combination of pre-delivery of static file metadata and receiver self generation of dynamic file metadata avoids the necessity of continuously sending the FDT-Instances for real-time objects. Such modified FDT functionality in ROUTE is referred to as the Extended FDT.
フルートでは、FDTインスタンスがバンドで配信され、送信者でオブジェクトがリアルタイムで生成される場合は、リアルタイムで生成および配信する必要があります。これらのFDTインスタンスには、[RFC6726]のセクション3.4.2で指定されているFDTとMBMS [MBMS]のセクション7.2.10と比較して、いくつかの違いがあります。重要な違いは、それが説明する配信オブジェクトからファイルメタデータを分離することに加えて、ルート内のFDT機能は、追加ファイルメタデータと、受信機がFDTのファイル要素のコンテンツロケーション属性を生成できるようにするルールによって拡張される可能性があることです。、 急いで。これは、FDTとLCTヘッダーへの拡張機能の両方で情報を使用することによって行われます。静的ファイルメタデータと受信機ダイナミックファイルメタデータのセルフ生成の前配信の組み合わせは、リアルタイムオブジェクトのFDTインスタンスを継続的に送信する必要性を回避します。ルート内のこのような変更されたFDT機能は、拡張FDTと呼ばれます。
As an extension to FLUTE, ROUTE allows for using EXT_TOL LCT header extension with 24 bits or, if required, 48 bits to signal the Transfer Length directly within the ROUTE packet.
フルートの拡張機能として、ルートでは、24ビットでext_tol LCTヘッダー拡張機能を使用するか、必要に応じて48ビットを使用して、ルートパケット内で直接転送長を信号することができます。
The transport object length can also be determined without the use of EXT_TOL by examining the LCT packet with the Close Object flag (B). However, if this packet is lost, then the EXT_TOL information can be used by the receiver to determine the transport object length.
トランスポートオブジェクトの長さは、Closeオブジェクトフラグ（b）を使用してLCTパケットを調べることにより、ext_tolを使用せずに決定することもできます。ただし、このパケットが失われた場合、ext_tol情報をレシーバーが使用して、トランスポートオブジェクトの長さを決定できます。
Applications using ROUTE for delivery of low-latency streaming content may make use of this feature for sender-end latency optimizations: the sender does not have to wait for the completion of the packaging of a whole Application Object to find its Transfer Length to be included in the FDT before the sending can start. Rather, partially encoded data can already be started to be sent via the ROUTE sender. As the time approaches when the encoding of the Application Object is nearing completion, and the length of the object becomes known (e.g., the time of writing the last CMAF Chunk of a DASH segment), only then the sender can signal the object length using the EXT TOL LCT header. For example, for a 2-second DASH segment with 100-millisecond chunks, it may result in saving up to 1.9 second latency at the sending end.
低遅延ストリーミングコンテンツの配信にルートを使用するアプリケーションは、送信者エンドのレイテンシ最適化のためにこの機能を使用する場合があります。送信者は、アプリケーションオブジェクト全体のパッケージングが完了するのを待つ必要がありません。送信前のFDTで開始できます。むしろ、部分的にエンコードされたデータは、ルート送信者を介してすでに送信されるように開始できます。アプリケーションオブジェクトのエンコードが完了に近づき、オブジェクトの長さが既知になったとき（たとえば、ダッシュセグメントの最後のCMAFチャンクを書き込む時間）に時間が近づくと、その場合にのみ、送信者はオブジェクトの長さを使用してオブジェクトの長さに信号を送信できます。ext tol lctヘッダー。たとえば、100ミリ秒のチャンクを備えた2秒のダッシュセグメントの場合、送信端で最大1.9秒のレイテンシーを節約する可能性があります。
The ROUTE repair protocol is FEC-based and is enabled as an additional layer between the transport layer (e.g., UDP) and the object delivery layer protocol. The FEC reuses concepts of the FEC Framework defined in RFC 6363 [RFC6363], but in contrast to the FEC Framework in RFC 6363 [RFC6363], the ROUTE repair protocol does not protect packets but instead protects delivery objects as delivered in the source protocol. In addition, as an extension to FLUTE, it supports the protection of multiple objects in one source block which is in alignment with the FEC Framework as defined in RFC 6363 [RFC6363]. Each FEC source block may consist of parts of a delivery object, as a single delivery object (similar to FLUTE) or multiple delivery objects that are bundled prior to FEC protection. ROUTE FEC makes use of FEC schemes in a similar way as those defined in RFC 5052 [RFC5052] and uses the terminology of that document. The FEC scheme defines the FEC encoding and decoding as well as the protocol fields and procedures used to identify packet payload data in the context of the FEC scheme.
ルート修理プロトコルはFECベースであり、輸送層（UDPなど）とオブジェクト配信レイヤープロトコルの間の追加レイヤーとして有効になっています。 FECは、RFC 6363 [RFC6363]で定義されているFECフレームワークの概念を再利用しますが、RFC 6363 [RFC6363]のFECフレームワークとは対照的に、ルート修復プロトコルはパケットを保護しませんが、ソースプロトコルで配信された配信オブジェクトを保護します。さらに、フルートの拡張として、RFC 6363 [RFC6363]で定義されているように、FECフレームワークと一致している1つのソースブロック内の複数のオブジェクトの保護をサポートします。各FECソースブロックは、配信オブジェクトの一部で構成され、単一の配信オブジェクト（フルートに類似）またはFEC保護の前にバンドルされた複数の配信オブジェクトとして構成されている場合があります。 Route FECは、RFC 5052 [RFC5052]で定義されているものと同様の方法でFECスキームを使用し、そのドキュメントの用語を使用します。 FECスキームは、FECスキームのコンテキストでパケットペイロードデータを識別するために使用されるプロトコルフィールドと手順と同様に、FECエンコードとデコードと手順を定義します。
In ROUTE, all packets are LCT packets as defined in RFC 5651 [RFC5651]. Source and repair packets may be distinguished by:
ルートでは、すべてのパケットはRFC 5651 [RFC5651]で定義されているLCTパケットです。ソースおよび修理パケットは、次のことによって区別される場合があります。
* Different ROUTE sessions, i.e., they are carried on different UDP/ IP port combinations.
* 異なるルートセッション、つまり、それらは異なるUDP/ IPポートの組み合わせで運ばれます。
* Different LCT channels, i.e., they use different TSI values in the LCT header.
* 異なるLCTチャネル、つまり、LCTヘッダーで異なるTSI値を使用します。
* The most significant PSI bit in the LCT, if carried in the same LCT channel. This mode of operation is mostly suitable for FLUTE-compatible deployments.
* 同じLCTチャネルで運ばれる場合、LCTで最も重要なPSIビット。この動作モードは、フルート互換の展開に主に適しています。
As noted in prevision sections, ATSC-ROUTE [ATSCA331] and DVB-MABR [DVBMABR] are considered services using this document that constrain specific features as well as add new ones. In this context, the following table is an informative comparison of the interoperability of ROUTE as specified in this document with ATSC-ROUTE [ATSCA331] and DVB-MABR [DVBMABR]:
予測セクションで述べたように、ATSC-Route [ATSCA331]およびDVB-MABR [DVBMABR]は、特定の機能を制約し、新しい機能を追加するこのドキュメントを使用してサービスを使用していると見なされます。これに関連して、次の表は、このドキュメントでATSC-Route [ATSCA331]およびDVB-MABR [DVBMABR]を使用して指定されているルートの相互運用性の有益な比較です。
+===============+===================+==================+============+
| Element | ATSC-ROUTE | This Document | DVB-MABR |
+===============+===================+==================+============+
| LCT header | PSI LSB set to 0 | Not defined | Set to 1 |
| field | for Source Flow | | for Source |
| | | | Flow for |
| | | | CMAF |
| | | | Random |
| | | | Access |
| | | | chunk |
| +-------------------+------------------+------------+
| | CCI may be set to | CCI may be set to EPT for |
| | 0 | Source Flow |
+---------------+-------------------+------------------+------------+
| LCT header | EXT_ROUTE_ | Not defined; | Shall not |
| extensions | PRESENTATION_TIME | may be added by | be used. |
| | Header used for | a profile. | |
| | Media Delivery | | |
| | Event (MDE) mode | | |
| +-------------------+------------------+------------+
| | EXT_TIME Header | EXT_TIME Header may be used |
| | linked to MDE | regardless (for FDT- |
| | mode in Annex | Instance@Expires |
| | A.3.7.2 | calculation) |
| | [ATSCA331] | |
+---------------+-------------------+------------------+------------+
| Codepoints | Full set | Does not | Restricted |
| | | specify range | to 5 - 9 |
| | | 11 - 255 | |
| | | (leaves to | |
| | | profiles) | |
+---------------+-------------------+------------------+------------+
| Session | Full set | Only defines a | Reuses |
| metadata | | small subset of | A/331 |
| | | data necessary | metadata, |
| | | for setting up | duplicated |
| | | Source and | from its |
| | | Repair Flows. | own |
| | | Does not define | Service |
| | | format or | signaling. |
| | | encoding of | |
| | | data except if | |
| | | data is | |
| | | integral/ | |
| | | alphanumerical. | |
| | | Leaves rest to | |
| | | profiles. | |
+---------------+-------------------+------------------+------------+
| Extended FDT | Instance shall | Not restricted, | Instance |
| | not be sent with | may be | shall not |
| | Source Flow | restricted by a | be sent |
| | | profile. | with |
| | | | Source |
| | | | Flow |
| +-------------------+------------------+------------+
| | No restriction | Only allowed in File Mode |
+---------------+-------------------+------------------+------------+
| Delivery | File, Entity, Signed/unsigned | Signed/ |
| Object Mode | package | unsigned |
| | | package |
| | | not |
| | | allowed |
+---------------+-------------------+------------------+------------+
| Sender | Defined for DASH | Defined for DASH segment and |
| operation: | segment | CMAF Chunks |
| Packetization | | |
+---------------+-------------------+-------------------------------+
| Receiver | Object handed to | Object may be handed before |
| object | application upon | completion if |
| recovery | complete | MPD@availabilityTimeOffset |
| | reception | signaled |
| +-------------------+-------------------------------+
| | - | Fast Stream acquisition |
| | | guidelines provided |
+---------------+-------------------+-------------------------------+
Table 3: Interoperability Chart
表3：相互運用性チャート
As noted in Section 9, ROUTE is aligned with FLUTE as specified in RFC 6726 [RFC6726] and only diverges in certain signaling optimizations, especially for the real-time object delivery case. Hence, most of the security considerations documented in RFC 6726 [RFC6726] for the data flow itself, the session metadata (session control parameters in RFC 6726 [RFC6726]), and the associated building blocks apply directly to ROUTE as elaborated in the following along with some additional considerations.
セクション9で述べたように、ルートはRFC 6726 [RFC6726]で指定されているフルートと整合しており、特にリアルタイムオブジェクト配信の場合、特定のシグナリング最適化でのみ分岐します。したがって、データフロー自体について、RFC 6726 [RFC6726]で文書化されたセキュリティに関する考慮事項のほとんどは、セッションメタデータ（RFC 6726 [RFC6726]のセッション制御パラメーター）、および関連するビルディングブロックは、以下に沿って詳しく説明されているようにルートに直接適用されます。いくつかの追加の考慮事項があります。
Both encryption and integrity protection applied either on file or packet level, as recommended in the file corruption considerations of RFC 6726 [RFC6726], SHOULD be used for ROUTE. Additionally, RFC 3740 [RFC3740] documents multicast security architecture in great detail with clear security recommendations that SHOULD be followed.
RFC 6726 [RFC6726]のファイルの破損に関する考慮事項で推奨されるように、ファイルまたはパケットレベルに適用される暗号化と整合性保護の両方が、ルートに使用する必要があります。さらに、RFC 3740 [RFC3740]は、マルチキャストセキュリティアーキテクチャを非常に詳細に文書化し、明確なセキュリティの推奨事項に従う必要があります。
When ROUTE is carried over UDP and a reverse channel from receiver to sender is available, the security mechanisms provided in RFC 9147 [RFC9147] SHOULD be applied.
ルートがUDPを介して運ばれ、受信機から送信者への逆チャネルが利用可能になる場合、RFC 9147 [RFC9147]で提供されるセキュリティメカニズムを適用する必要があります。
In regard to considerations for attacks against session description, this document does not specify the semantics or mechanism of delivery of session metadata, though the same threats apply for service using ROUTE as well. Hence, a service using ROUTE SHOULD take these threats into consideration and address them appropriately following the guidelines provided by RFC 6726 [RFC6726]. Additionally, to the recommendations of RFC 6726 [RFC6726], for Internet connected devices, services SHOULD enable clients to access the session description information using HTTPS with customary authentication/ authorization, instead of sending this data via multicast/broadcast, since considerable security work has been done already in this unicast domain, which can enable highly secure access of session description data. Accessing via unicast, however, will have different privacy considerations, noted in Section 11.2. Note that in general the multicast/broadcast stream is delayed with respect to the unicast stream. Therefore, the session description protocol SHOULD be time synchronized with the broadcast stream, particularly if the session description contains security-related information.
セッションの説明に対する攻撃の考慮事項に関して、このドキュメントでは、セッションメタデータの送達のセマンティクスまたはメカニズムを指定しませんが、同じ脅威はルートを使用したサービスにも適用されます。したがって、ルートを使用するサービスは、これらの脅威を考慮し、RFC 6726 [RFC6726]によって提供されたガイドラインに従って適切に対処する必要があります。さらに、RFC 6726 [RFC6726]の推奨事項には、インターネット接続デバイスの場合、サービスはマルチキャスト/ブロードキャストを介してこのデータを送信する代わりに、慣習的な認証/認証を使用してHTTPSを使用してセッションの説明情報にアクセスできるようにする必要があります。このユニキャストドメインですでに行われているため、セッションの説明データに非常に安全にアクセスできます。ただし、ユニキャストを介してアクセスするには、セクション11.2に記載されているさまざまなプライバシーに関する考慮事項があります。一般に、マルチキャスト/ブロードキャストストリームはユニキャストストリームに関して遅延していることに注意してください。したがって、特にセッションの説明にセキュリティ関連の情報が含まれている場合、セッションの説明プロトコルはブロードキャストストリームと時間同期する必要があります。
In regard to FDT, there is one key difference for File Mode when using File Template in EFDT, which avoids repeated sending of FDT-Instances and hence, the corresponding threats noted in RFC 6726 [RFC6726] do not apply directly to ROUTE in this case. The threat, however, is shifted to the ALC/LCT headers, since they carry the additional signaling that enables determining Content-Location and File@Transfer-Length in this case. Hence, integrity protection recommendations of ALC/LCT header SHOULD be considered with higher emphasis in this case for ROUTE.
FDTに関しては、EFDTでファイルテンプレートを使用する場合、ファイルモードには1つの重要な違いがあります。これにより、FDTインスタンスの繰り返しの送信を回避するため、RFC 6726 [RFC6726]で記載されている対応する脅威は、この場合のルートに直接適用されません。。ただし、脅威はALC/LCTヘッダーにシフトされます。これは、この場合、コンテンツロケーションとファイル@onlengthengentを決定できる追加のシグナルを運ぶためです。したがって、ALC/LCTヘッダーの整合性保護の推奨事項は、この場合、ルートについてより重点を置いて考慮する必要があります。
Finally, attacks against the congestion control building block for the case of ROUTE can impact the optional fast stream acquisition specified in Section 6.2. Receivers SHOULD have robustness against timestamp values that are suspicious, e.g., by comparing the signaled time in the LCT headers with the approximate time signaled by the MPD, and SHOULD discard outlying values. Additionally, receivers MUST adhere to the expiry timelines as specified in Section 6. Integrity protection mechanisms documented in RFC 6726 [RFC6726] SHOULD be used to address this threat.
最後に、ルートの場合の混雑制御ビルディングブロックに対する攻撃は、セクション6.2で指定されたオプションの高速ストリーム取得に影響を与える可能性があります。レシーバーは、たとえば、LCTヘッダーの信号時間をMPDによって信号を送信する近似時間と比較することにより、疑わしいタイムスタンプの値に対して堅牢性を持つ必要があります。さらに、セクション6で指定されているように、受信機は有効期限のタイムラインを遵守する必要があります。RFC6726[RFC6726]に文書化された整合性保護メカニズムは、この脅威に対処するために使用する必要があります。
Encryption mechanisms recommended for security considerations in Section 11.1 SHOULD also be applied to enable privacy and protection from snooping attacks.
セクション11.1のセキュリティに関する考慮事項に推奨される暗号化メカニズムも、プライバシーとスヌーピング攻撃からの保護を可能にするために適用する必要があります。
Since this protocol is primarily targeted for IP multicast/broadcast environments where the end user is mostly listening, identity protection and user data retention considerations are more protected than in the unicast case. Best practices for enabling privacy on IP multicast/broadcast SHOULD be applied by the operators, e.g., "Recommendations for DNS Privacy Service Operators" in RFC 8932 [RFC8932].
このプロトコルは主に、エンドユーザーがほとんどリスニングしているIPマルチキャスト/ブロードキャスト環境を対象としているため、アイデンティティ保護とユーザーデータ保持の考慮事項は、ユニキャストの場合よりも保護されています。IPマルチキャスト/ブロードキャストでプライバシーを有効にするためのベストプラクティスは、RFC 8932 [RFC8932]の「DNSプライバシーサービスオペレーターの推奨」、「DNSプライバシーサービスオペレーターの推奨」など、オペレーターによって適用される必要があります。
However, if clients access session description information via HTTPS, the same privacy considerations and solutions SHALL apply to this access as for regular HTTPS communication, an area that is very well studied and the concepts of which are being integrated directly into newer transport protocols such as IETF QUIC [RFC9000] enabling HTTP/3 [HTTP3]. Hence, such newer protocols SHOULD be used to foster privacy.
ただし、クライアントがHTTPSを介してセッションの説明情報にアクセスした場合、通常のHTTPS通信、非常によく研究されている領域とその概念が直接統合されているような新しい輸送プロトコルに直接統合されているのと同じプライバシーに関する考慮事項とソリューションがこのアクセスに適用されます。IETF QUIC [RFC9000] HTTP/3 [HTTP3]を有効にします。したがって、このような新しいプロトコルを使用して、プライバシーを促進する必要があります。
Note that streaming services MAY contain content that may only be accessed via DRM (digital rights management) systems. DRM systems can prevent unauthorized access to content delivered via ROUTE.
ストリーミングサービスには、DRM（デジタル権利管理）システムを介してのみアクセスできるコンテンツが含まれている場合があることに注意してください。DRMシステムは、ルートを介して配信されるコンテンツへの不正アクセスを防ぐことができます。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[ATSCA331] Advanced Television Systems Committee, "Signaling, Delivery, Synchronization, and Error Protection", ATSC Standard A/331:2022-03, March 2022.
[ATSCA331]高度なテレビシステム委員会、「シグナリング、配信、同期、エラー保護」、ATSC標準A/331：2022-03、2022年3月。
[RFC1952] Deutsch, P., "GZIP file format specification version 4.3", RFC 1952, DOI 10.17487/RFC1952, May 1996, <https://www.rfc-editor.org/info/rfc1952>.
[RFC1952] Deutsch、P。、「GZIPファイル形式の仕様バージョン4.3」、RFC 1952、DOI 10.17487/RFC1952、1996年5月、<https://www.rfc-editor.org/info/rfc1952>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC2557] Palme, J., Hopmann, A., and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999, <https://www.rfc-editor.org/info/rfc2557>.
[RFC2557] Palme、J.、Hopmann、A。、およびN. Shelness、「HTML（MHTML）などの集計文書のMIMEカプセル化」、RFC 2557、DOI 10.17487/RFC2557、1999年3月、<HTTPS：//.rfc-editor.org/info/rfc2557>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC5052] Watson, M., Luby, M., and L. Vicisano, "Forward Error Correction (FEC) Building Block", RFC 5052, DOI 10.17487/RFC5052, August 2007, <https://www.rfc-editor.org/info/rfc5052>.
[RFC5052] Watson、M.、Luby、M.、およびL. Vicisano、「フォワードエラー補正（FEC）ビルディングブロック」、RFC 5052、DOI 10.17487/RFC5052、2007年8月、<https：//www.rfc-editor.org/info/rfc5052>。
[RFC5445] Watson, M., "Basic Forward Error Correction (FEC) Schemes", RFC 5445, DOI 10.17487/RFC5445, March 2009, <https://www.rfc-editor.org/info/rfc5445>.
[RFC5445] Watson、M。、「Basic Forward Error Correction（FEC）Schemes」、RFC 5445、DOI 10.17487/RFC5445、2009年3月、<https://www.rfc-editor.org/info/rfc545>
[RFC5651] Luby, M., Watson, M., and L. Vicisano, "Layered Coding Transport (LCT) Building Block", RFC 5651, DOI 10.17487/RFC5651, October 2009, <https://www.rfc-editor.org/info/rfc5651>.
[RFC5651] Luby、M.、Watson、M.、およびL. Vicisano、「レイヤードコーディング輸送（LCT）ビルディングブロック」、RFC 5651、DOI 10.17487/RFC5651、2009年10月、<https：//www.rfc-editor.org/info/rfc5651>。
[RFC5775] Luby, M., Watson, M., and L. Vicisano, "Asynchronous Layered Coding (ALC) Protocol Instantiation", RFC 5775, DOI 10.17487/RFC5775, April 2010, <https://www.rfc-editor.org/info/rfc5775>.
[RFC5775] Luby、M.、Watson、M.、およびL. Vicisano、「非同期層コーディング（ALC）プロトコルインスタンス化」、RFC 5775、DOI 10.17487/RFC5775、2010年4月、<https：//www.rfc-editor.org/info/rfc5775>。
[RFC6330] Luby, M., Shokrollahi, A., Watson, M., Stockhammer, T., and L. Minder, "RaptorQ Forward Error Correction Scheme for Object Delivery", RFC 6330, DOI 10.17487/RFC6330, August 2011, <https://www.rfc-editor.org/info/rfc6330>.
[RFC6330] Luby、M.、Shokrollahi、A.、Watson、M.、Stockhammer、T.、およびL. Minder、「Raptorq Forward Error Correction Scheme for Object Object Derviraly」、RFC 6330、DOI 10.17487/RFC6330、2011年8月、2011年8月、<https://www.rfc-editor.org/info/rfc6330>。
[RFC6363] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <https://www.rfc-editor.org/info/rfc6363>.
[RFC6363] Watson、M.、Begen、A。、およびV. Roca、「Forward Error Correction（FEC）Framework」、RFC 6363、DOI 10.17487/RFC6363、2011年10月、<https：//www.rfc-editor。org/info/rfc6363>。
[RFC6726] Paila, T., Walsh, R., Luby, M., Roca, V., and R. Lehtonen, "FLUTE - File Delivery over Unidirectional Transport", RFC 6726, DOI 10.17487/RFC6726, November 2012, <https://www.rfc-editor.org/info/rfc6726>.
[RFC6726] Paila、T.、Walsh、R.、Luby、M.、Roca、V。、およびR. Lehtonen、「フルート - 単方向輸送に対するファイル配信」、RFC 6726、DOI 10.17487/RFC6726、2012年11月、<<<https://www.rfc-editor.org/info/rfc6726>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、ed。and J. Reschke、ed。、「HyperText Transfer Protocol（HTTP/1.1）：Semantics and Content」、RFC 7231、DOI 10.17487/RFC7231、2014年6月、<https://www.rfc-editor.org/info/RFC7231>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification", RFC 8551, DOI 10.17487/RFC8551, April 2019, <https://www.rfc-editor.org/info/rfc8551>.
[RFC8551] Schaad、J.、Ramsdell、B。、およびS. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン4.0メッセージ仕様」、RFC 8551、DOI 10.17487/RFC8551、2019年4月、<HTTPS：//www.rfc-editor.org/info/rfc8551>。
[CMAF] International Organization for Standardization, "Information technology -- Multimedia application format (MPEG-A) -- Part 19: Common media application format (CMAF) for segmented media", First edition, ISO/IEC FDIS 23000-19, January 2018, <https://www.iso.org/standard/71975.html>.
[CMAF]国際標準化機関、「情報技術 - マルチメディアアプリケーションフォーマット（MPEG-A） - パート19：セグメント化されたメディアの共通メディアアプリケーション形式（CMAF）」、初版、ISO/IEC FDIS 23000-19、1月2018、<https://www.iso.org/standard/71975.html>。
[DASH] International Organization for Standardization, "Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats", Fourth edition, ISO/IEC 23009-1:2019, December 2019, <https://www.iso.org/standard/79329.html>.
[DASH]国際標準化機関、「情報技術 - HTTP（DASH）上の動的適応ストリーミング - パート1：メディアプレゼンテーションの説明とセグメント形式」、第4版、ISO/IEC 23009-1：2019、2019年12月、<HTTPS：//www.iso.org/standard/79329.html>。
[DVBMABR] ETSI, "Digital Video Broadcasting (DVB); Adaptive media streaming over IP multicast", version 1.1.1, ETSI TS 103 769, November 2020.
[DVBMABR] ETSI、「Digital Video Broadcasting（DVB）; IP Multicastを介したアダプティブメディアストリーミング」、バージョン1.1.1、ETSI TS 103 769、2020年11月。
[HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf-quic-http-34, 2 February 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34>.
[HTTP3] Bishop、M.、ed。、「HyperText Transfer Protocolバージョン3（HTTP/3）」、Work in Progress、Internet-Draft、Draft-Itef-Quic-Http-34、2021年2月2日、<https：//datatracker.ietf.org/doc/html/draft-ietf-quic-http-34>。
[MBMS] ETSI, "Universal Mobile Telecommunications Systems (UMTS);
LTE; 5G; Multimedia Broadcast/Multicast Service (MBMS);
Protocols and codecs", version 16.9.1, ETSI TS 126 346,
May 2021.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, DOI 10.17487/RFC3740, March 2004, <https://www.rfc-editor.org/info/rfc3740>.
[RFC3740] Hardjono、T。およびB. Weis、「マルチキャストグループセキュリティアーキテクチャ」、RFC 3740、DOI 10.17487/RFC3740、2004年3月、<https://www.rfc-editor.org/info/rfc3740>
[RFC6968] Roca, V. and B. Adamson, "FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols", RFC 6968, DOI 10.17487/RFC6968, July 2013, <https://www.rfc-editor.org/info/rfc6968>.
[RFC6968] Roca、V.およびB. Adamson、「Fcast：非同期層コーディング（ALC）およびNACK指向の信頼できるマルチキャスト（NORM）プロトコルのオブジェクト配信」、RFC 6968、DOI 10.17487/RFC6968、2013年7月、<HTPS <HTPS：//www.rfc-editor.org/info/rfc6968>。
[RFC8932] Dickinson, S., Overeinder, B., van Rijswijk-Deij, R., and A. Mankin, "Recommendations for DNS Privacy Service Operators", BCP 232, RFC 8932, DOI 10.17487/RFC8932, October 2020, <https://www.rfc-editor.org/info/rfc8932>.
[RFC8932] Dickinson、S.、Overeinder、B.、Van Rijswijk-Deij、R。、およびA. Mankin、「DNSプライバシーサービスオペレーターの推奨」、BCP 232、RFC 8932、DOI 10.17487/RFC8932、10月2020年、<<<<<https://www.rfc-editor.org/info/rfc8932>。
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, <https://www.rfc-editor.org/info/rfc9000>.
[RFC9000] Iyengar、J.、ed。and M. Thomson、ed。、「Quic：UDPベースの多重化および安全な輸送」、RFC 9000、DOI 10.17487/RFC9000、2021年5月、<https://www.rfc-editor.org/info/rfc9000>
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.
[RFC9147] Rescorla、E.、Tschofenig、H。、およびN. Modadugu、「データグラム輸送層セキュリティ（DTLS）プロトコルバージョン1.3」、RFC 9147、DOI 10.17487/RFC9147、2022年4月、<https：// www。rfc-editor.org/info/rfc9147>。
Acknowledgments
謝辞
As outlined in the introduction and in ROUTE concepts in Section 9, the concepts specified in this document are the culmination of the collaborative work of several experts and organizations over the years. The authors would especially like to acknowledge the work and efforts of the following people and organizations to help realize the technologies described in this document (in no specific order): Mike Luby, Kent Walker, Charles Lo, and other colleagues from Qualcomm Incorporated, LG Electronics, Nomor Research, Sony, and BBC R&D.
セクション9の紹介とルートの概念で概説されているように、このドキュメントで指定された概念は、長年にわたるいくつかの専門家や組織の共同作業の集大成です。著者は、この文書に記載されているテクノロジーの実現を支援するために、次の人々と組織の仕事と努力を特に認めたいと考えています（特定の順序で）：Mike Luby、Kent Walker、Charles Lo、およびQualcomm Incorporatedの他の同僚、LGエレクトロニクス、ノモアリサーチ、ソニー、およびBBC R＆D。
Authors' Addresses
著者のアドレス
Waqar Zia Qualcomm CDMA Technologies GmbH Anzinger Str. 13 81671 Munich Germany Email: wzia@qti.qualcomm.com
Waqar Zia Qualcomm CDMA Technologies GmbH Anzinger str。13 81671ミュンヘンドイツメール：wzia@qti.qualcomm.com
Thomas Stockhammer Qualcomm CDMA Technologies GmbH Anzinger Str. 13 81671 Munich Germany Email: tsto@qti.qualcomm.com
Thomas Stockhammer Qualcomm CDMA Technologies GmbH Anzinger str。13 81671ミュンヘンドイツメール：tsto@qti.qualcomm.com
Lenaig Chaponniere Qualcomm Technologies Inc. 5775 Morehouse Drive San Diego, CA 92121 United States of America Email: lguellec@qti.qualcomm.com
Lenaig Chaponniere Qualcomm Technologies Inc.
Giridhar Mandyam Qualcomm Technologies Inc. 5775 Morehouse Drive San Diego, CA 92121 United States of America Email: mandyam@qti.qualcomm.com
Giridhar Mandyam Qualcomm Technologies Inc.
Michael Luby BitRipple, Inc. 1133 Miller Ave Berkeley, CA 94708 United States of America Email: luby@bitripple.com
Michael Luby Bitripple、Inc。1133 Miller Ave Berkeley、CA 94708アメリカ合衆国メールメール：luby@bitripple.com