[要約] RFC 5163は、Unidirectional Lightweight Encapsulation（ULE）およびGeneric Stream Encapsulation（GSE）の拡張形式に関する仕様です。このRFCの目的は、ULEおよびGSEの拡張形式を定義し、これらのプロトコルの柔軟性と拡張性を向上させることです。
Network Working Group G. Fairhurst
Request for Comments: 5163 University of Aberdeen
Category: Standards Track B. Collini-Nocker
University of Salzburg
April 2008
Extension Formats for Unidirectional Lightweight Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)
単方向の軽量カプセル化（ULE）および汎用ストリームカプセル化（GSE）の拡張形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Abstract
概要
This document describes a set of Extension Headers for the Unidirectional Lightweight Encapsulation (ULE), RFC 4326.
このドキュメントでは、単方向の軽量カプセル化（ULE）、RFC 4326の拡張ヘッダーのセットについて説明します。
The Extension Header formats specified in this document define extensions appropriate to both ULE and the Generic Stream Encapsulation (GSE) for the second-generation framing structure defined by the Digital Video Broadcasting (DVB) family of specifications.
このドキュメントで指定されている拡張ヘッダー形式は、Digital Video Broadcasting（DVB）仕様ファミリーによって定義された第2世代のフレーミング構造のために、ULEと汎用ストリームカプセル化（GSE）の両方に適した拡張機能を定義します。
Table of Contents
目次
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Description of the Method .......................................4
3.1. MPEG-2 TS-Concat Extension .................................5
3.2. PDU-Concat Extension .......................................8
3.3. TimeStamp Extension .......................................12
4. IANA Considerations ............................................13
5. Acknowledgments ................................................13
6. Security Considerations ........................................14
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
Appendix A. The Second-Generation DVB Transmission
Specifications .................................................16
This document describes three Extension Headers that may be used with both the Unidirectional Lightweight Encapsulation (ULE) [RFC4326] and the Generic Stream Encapsulation (GSE) [GSE]. ULE is defined for links that employ the MPEG-2 Transport Stream, and supports a wide variety of physical-layer bearers [RFC4259].
このドキュメントでは、単方向の軽量カプセル化（ULE）[RFC4326]と汎用ストリームカプセル化（GSE）[GSE]の両方で使用できる3つの拡張ヘッダーについて説明します。ULEは、MPEG-2トランスポートストリームを使用するリンクに対して定義され、さまざまな物理的層のベアラーをサポートします[RFC4259]。
GSE has been designed for the Generic Mode (also known as the Generic Stream (GS)), offered by second-generation DVB physical layers, and in the first instance for DVB-S2 [ETSI-S2]. The requirements for the Generic Stream are described in [S2-REQ]. The important characteristics of this encapsulation are described in the appendix of this document. GSE maintains a design philosophy that presents a network interface that is common to that presented by ULE and uses a similar construction for SubNetwork Data Units (SNDUs).
GSEは、ジェネリックモード（ジェネリックストリーム（GS）とも呼ばれる）用に設計されており、第2世代のDVB物理層によって提供され、最初はDVB-S2 [ETSI-S2]で提供されています。一般的なストリームの要件は[S2-Req]で説明されています。このカプセル化の重要な特性については、このドキュメントの付録に記載されています。GSEは、ULEが提示したものと共通するネットワークインターフェイスを提示する設計哲学を維持し、サブネットワークデータユニット（SNDU）に同様の構造を使用しています。
The first Extension Header defines a method that allows one or more TS Packets [ISO-MPEG2] to be sent within a ULE SNDU. This method may be used to provide control plane information including the transmission of MPEG-2 Program Specific Information (PSI) for the Multiplex. In GSE, there is no native support for Transport Stream packets and this method is therefore suitable for providing an MPEG-2 control plane.
最初の拡張ヘッダーは、1つ以上のTSパケット[ISO-MPEG2]をULE SNDU内で送信できるようにするメソッドを定義します。この方法は、マルチプレックスのMPEG-2プログラム固有の情報（PSI）の送信を含む制御プレーン情報を提供するために使用できます。GSEでは、輸送ストリームパケットに対するネイティブサポートはありません。したがって、この方法はMPEG-2コントロールプレーンの提供に適しています。
A second Extension Header allows one or more PDUs to be sent within the same ULE SNDU. This method is designed for cases where a large number of small PDUs are directed to the same Network Point of Attachment (NPA) address. The method may improve transmission efficiency (by removing duplicated MAC layer overhead). It can also reduce processing overhead for a receiver that is not configured to receive the NPA address associated with an SNDU, allowing this receiver to then skip several PDUs in one operation. The method is defined as a generic Extension Header and may be used for IPv4 or IPv6 packets. If, and when, a compression format is defined for ULE or Ethernet, the method may also be used in combination with this method.
2番目の拡張ヘッダーを使用すると、同じULE SNDU内で1つ以上のPDUを送信できます。この方法は、多数の小さなPDUが同じネットワークポイントの添付ファイル（NPA）アドレスに向けられている場合に設計されています。この方法は、送信効率を改善する可能性があります（重複したMACレイヤーのオーバーヘッドを削除することにより）。また、SNDUに関連付けられたNPAアドレスを受信するように構成されていないレシーバーのオーバーヘッドを削減し、このレシーバーが1つの操作で複数のPDUをスキップできるようにすることができます。このメソッドは、一般的な拡張ヘッダーとして定義され、IPv4またはIPv6パケットに使用できます。ULEまたはイーサネットに対して圧縮形式が定義されている場合、この方法もこの方法と組み合わせて使用できます。
A third Extension Header provides an optional TimeStamp value for an SNDU. Examples of the use of this TimeStamp option include monitoring and benchmarking of ULE and GSE links. Receivers that do not wish to decode (or do not support) the TimeStamp extension may discard the extension and process the remaining PDU or Extension Headers.
3番目の拡張ヘッダーは、SNDUのオプションのタイムスタンプ値を提供します。このタイムスタンプオプションの使用の例には、ULEおよびGSEリンクの監視とベンチマークが含まれます。タイムスタンプの拡張機能をデコードしたくない（またはサポートしない）受信者は、拡張機能を破棄し、残りのPDUまたは拡張ヘッダーを処理する場合があります。
The appendix includes a summary of key design issues and considerations relating to the GSE Specification defined by the DVB Technical Module [GSE].
付録には、DVBテクニカルモジュール[GSE]によって定義されたGSE仕様に関連する主要な設計の問題と考慮事項の概要が含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]で説明されているように解釈されます。
b: bit. For example, one byte consists of 8b.
B：ビット。たとえば、1つのバイトは8bで構成されています。
B: byte. Groups of bytes are represented in Internet byte order.
B：バイト。バイトのグループは、インターネットバイトの順序で表されます。
BBFrame payload: The data field part of a Baseband frame [ETSI-S2] that may be used for the communication of data. Typical BBFrames range in size from 3072 to 58192 bits according to the choice of modulation format and Forward Error Correction (FEC) in use.
BBFRAMEペイロード：データの通信に使用できるベースバンドフレーム[ETSI-S2]のデータフィールド部分。典型的なBBFramesは、使用中の変調形式と前方エラー補正（FEC）の選択に応じて、3072から58192ビットのサイズの範囲です。
DVB: Digital Video Broadcasting. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data.
DVB：デジタルビデオ放送。ビデオ、オーディオ、およびデータの送信のために、欧州通信標準研究所（ETSI）が発行した関連基準のフレームワークとセット。
E: A one-bit flag field defined in GSE [GSE].
Encapsulator: A network device [RFC4259] that receives PDUs and formats these into Payload Units (known here as SNDUs) for output in DVB-S or the Generic Mode of DVB-S2.
Encapsulator：PDUを受信し、これらをDVB-SまたはDVB-S2のジェネリックモードの出力のペイロードユニット（ここで知られている）にフォーマットするネットワークデバイス[RFC4259]。
GS: Generic Stream. A stream of BBFrames identified by a common Input Stream Identifier, and which does not use the MPEG-2 TS format [ETSI-S2]. It represents layer 2 of the ISO/OSI reference model.
GS：一般的なストリーム。共通の入力ストリーム識別子によって識別され、MPEG-2 TS形式[ETSI-S2]を使用していないBBFramesのストリーム。ISO/OSI参照モデルのレイヤー2を表します。
GSE: Generic Stream Encapsulation [GSE]. A method for encapsulating PDUs to form a Generic Stream, which is sent using a sequence of BBFrames. This encapsulation format shares the same extension format and basic processing rules of ULE and uses a common IANA Registry.
GSE：ジェネリックストリームカプセル化[GSE]。PDUをカプセル化して一般的なストリームを形成する方法。これは、一連のBBFramesを使用して送信されます。このカプセル化形式は、ULEの同じ拡張機能形式と基本処理ルールを共有し、一般的なIANAレジストリを使用します。
LT: A two-bit flag field defined in GSE [GSE].
LT：GSE [GSE]で定義された2ビットフラグフィールド。
MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard.
MAC：中アクセスコントロール[IEEE-802.3]。IEEE 802.3標準で定義されたリンク層プロトコル。
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Organization for Standardization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
MPEG-2：Motion Picture Experts Group（MPEG）によって指定され、国際標準化機関（ISO/IEC 113818-1）[ISO-MPEG2]およびITU-T（H.220の標準化された一連の基準））。
Next-Header: A Type value indicating an Extension Header [RFC4326].
Next-Header：拡張ヘッダー[RFC4326]を示すタイプ値。
NPA: Network Point of Attachment [RFC4326]. In this document, refers to a destination address (resembling an IEEE MAC address) within the DVB-S/S2 transmission network that is used to identify individual Receivers or groups of Receivers.
NPA：ネットワークポイントの添付ファイル[RFC4326]。このドキュメントでは、個々の受信機または受信機のグループを識別するために使用されるDVB-S/S2送信ネットワーク内の宛先アドレス（IEEE Macアドレスに似ています）を指します。
PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the header of each TS Packet. This identifies the TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the parts of a Table Section or other Payload Unit must all carry the same PID value. The all-ones PID value indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes.
PID：パケット識別子[ISO-MPEG2]。各TSパケットのヘッダーに搭載された13ビットフィールド。これは、TSパケットが属するTS論理チャネルを識別します[ISO-MPEG2]。テーブルセクションまたはその他のペイロードユニットの部分を形成するTSパケットは、すべて同じPID値を持つ必要があります。すべてのPID値は、TSマルチプレックスの一定のビットレートを維持するために導入されたNULL TSパケットを示します。異なるTSマルチプレックスを使用して送信されるTS論理チャネルに使用されるPID値の間に必要な関係はありません。
PDU: Protocol Data Unit [RFC4259]. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PDU：プロトコルデータユニット[RFC4259]。PDUの例には、イーサネットフレーム、IPv4またはIPv6データグラム、その他のネットワークパケットが含まれます。
PSI: Program Specific Information [ISO-MPEG2].
PSI：プログラム固有の情報[ISO-MPEG2]。
S: A one-bit flag field defined in [GSE].
S：[GSE]で定義された1ビットフラグフィールド。
SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is been defined by another standards body to convey information about the services carried on a DVB Multiplex.
SIテーブル：サービス情報テーブル[ISO-MPEG2]。このドキュメントでは、この用語では、DVBマルチプレックスで運ばれるサービスに関する情報を伝えるために別の標準機関によって定義されたテーブルについて説明します。
SNDU: SubNetwork Data Unit [RFC4259]. In this document, this is an encapsulated PDU sent using ULE or GSE.
SNDU：サブネットワークデータユニット[RFC4259]。このドキュメントでは、これはULEまたはGSEを使用して送信されるカプセル化されたPDUです。
Stream: A logical flow from an Encapsulator to a set of Receivers.
ストリーム：カプセレータからレシーバーのセットへの論理的なフロー。
TS: Transport Stream [ISO-MPEG2], a method of transmission at the MPEG-2 level using TS Packets; it represents layer 2 of the ISO/OSI reference model.
TS：TSパケットを使用したMPEG-2レベルでの伝送方法であるTransport Stream [ISO-MPEG2]。ISO/OSI参照モデルのレイヤー2を表します。
ULE: Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. A method that encapsulates PDUs into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel. The encapsulation defines an extension format and an associated IANA Registry.
ULE：単方向の軽量カプセル化（ULE）[RFC4326]。単一のTS論理チャネルを使用して一連のTSパケットで送信されるSNDUにPDUをカプセル化するメソッド。カプセル化は、拡張形式と関連するIANAレジストリを定義します。
In ULE, a Type field value that is less than 1536 in decimal indicates an Extension Header. This section describes a set of three extension formats for the ULE encapsulation. [GSE] uses a Type field that adopts the same semantics as specified by RFC 4326. The encapsulation format differs in that GSE does not include a Cyclic Redundancy Check (CRC) for each SNDU, has different header flags, and utilizes a different SNDU length calculation [GSE].
ULEでは、10進数で1536未満のタイプフィールド値は、拡張ヘッダーを示します。このセクションでは、ULEカプセル化の3つの拡張形式のセットについて説明します。[GSE]は、RFC 4326で指定されたのと同じセマンティクスを採用するタイプフィールドを使用します。GSEには、各SNDUの環状冗長チェック（CRC）が含まれていないという点で、カプセル化形式は異なり、異なるヘッダーフラグがあり、異なるSNDUの長さを利用します。計算[GSE]。
There is a natural ordering of Extension Headers, which is determined by the fields upon which the Extension Header operates. A suitable ordering for many applications is presented in the list below (from first to last header within an SNDU). This does not imply that all types of Extensions should be present in a single SNDU. The presented ordering may serve as a guideline for optimization of Receiver processing.
拡張ヘッダーの自然な順序付けがあり、これは拡張ヘッダーが動作するフィールドによって決定されます。多くのアプリケーションの適切な注文は、以下のリストに示されています（SNDU内の最初のヘッダーから最後のヘッダーまで）。これは、すべてのタイプの拡張機能が単一のSNDUに存在することを意味するものではありません。提示された注文は、受信機処理の最適化のためのガイドラインとして機能する場合があります。
+----------------------------------+-------------------------------+
|Fields related to Extension Header| Example Extension Headers |
+----------------------------------+-------------------------------+
| Link framing and transmission | TimeStamp Extension |
+----------------------------------+-------------------------------+
| Entire remaining SNDU Payload | Encryption Extension |
+----------------------------------+-------------------------------+
| Group of encapsulated PDUs | PDU-Concat or TS-Concat |
+----------------------------------+-------------------------------+
| Specific encapsulated PDU | IEEE-defined type |
| | Test or MAC bridging Extension|
+----------------------------------+-------------------------------+
Table 1: Recommended ordering of Extension Headers
表1：拡張ヘッダーの推奨注文
The MPEG-2 TS-Concat Extension Header is specified by an IANA-assigned H-Type value of 0x0002 in hexadecimal. This is a Mandatory Extension Header.
MPEG-2 TS-CONCAT拡張ヘッダーは、16進数のIANAが割り当てられたH型値0x0002で指定されています。これは必須の拡張ヘッダーです。
The extension is used to transport one or more MPEG-2 TS Packets within a ULE SNDU. The number of TS Packets carried in a specific SNDU is determined from the size of the remainder of the payload following the MPEG-2 TS Extension Header. The number of TS Packets contained in the SNDU is therefore (Length-N-10+D*6) / 188, where N is the number of bytes associated with Extension Headers that precede the MPEG-2 TS-Concat Extension (zero if there are none) and D is the value of the D-bit.
拡張機能は、1つ以上のMPEG-2 TSパケットをULE SNDU内に輸送するために使用されます。特定のSNDUで運ばれるTSパケットの数は、MPEG-2 TS拡張ヘッダーに続くペイロードの残りのサイズから決定されます。したがって、SNDUに含まれるTSパケットの数は（長さn-10 d*6） / 188です。ここで、nはmpeg-2 ts-concat拡張に先行する拡張ヘッダーに関連するバイト数です（ある場合はゼロなし）およびdはd-bitの値です。
A Receiver MUST check the validity of the Length value prior to processing the payload. A valid Length corresponds to an integral number of TS Packets. An invalid Length (a remainder from the division by 188) MUST result in the discard of all encapsulated TS Packets and SHOULD be recorded as TS-Concat size mismatch error.
受信者は、ペイロードを処理する前に、長さの値の有効性を確認する必要があります。有効な長さは、積分数のTSパケットに対応します。無効な長さ（188までに部門からの残り）は、すべてのカプセル化されたTSパケットの破棄をもたらす必要があり、TS-CONCATサイズの不一致エラーとして記録する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ULE/SNDU Format for a TS-Packet Payload (D=0)
図1：TSパケットペイロードのULE/SNDU形式（d = 0）
Figure 1 illustrates the format of this Extension Header for ULE with a value D=0, which indicates the presence of an NPA address [RFC4326]. In this case, the valid payload Length for a ULE SNDU with no other extensions is (Length-10) / 188.
図1は、値d = 0のULEのこの拡張ヘッダーの形式を示しています。これは、NPAアドレス[RFC4326]の存在を示しています。この場合、他の拡張機能がないULE SNDUの有効なペイロード長は（長さ-10） / 188です。
The method used to define the Length in GSE differs to that of ULE. The equivalent case for GSE would result in a payload Length value of (Length-6) / 188 (Figure 2).
GSEの長さを定義するために使用される方法は、ULEの長さとは異なります。GSEの同等のケースは、ペイロード長値（長さ-6） / 188（図2）になります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|0 0| Length (12b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: GSE/SNDU Format for a TS-Packet Payload (LT=00)
図2：TSパケットペイロードのGSE/SNDU形式（LT = 00）
Fragmented GSE SNDUs are protected by a CRC-32 carried in the final fragment. After reassembly, this CRC-32 is removed and the resulting SNDU carries a Total Length field. The fields labeled S and E are defined by [GSE] and contain control flags used by the GSE link layer. The Label Type (LT) field specifies the presence and format of the GSE label. The LT field is only specified for the first fragment (or a non-fragmented) GSE SNDU (i.e., when S=1).
断片化されたGSE SNDUは、最終的なフラグメントに運ばれるCRC-32によって保護されています。再組み立て後、このCRC-32が削除され、結果のSNDUが総長さフィールドを搭載します。sとeというラベルのあるフィールドは[gse]で定義され、GSEリンク層で使用される制御フラグが含まれています。ラベルタイプ（LT）フィールドは、GSEラベルの存在と形式を指定します。LTフィールドは、最初のフラグメント（または非フラグメントされていない）GSE SNDU（つまり、S = 1の場合）にのみ指定されます。
In ULE, a value of D=1 is also permitted and indicates the absence of an NPA address (Figure 3). A similar format is supported in GSE.
ULEでは、d = 1の値も許可されており、NPAアドレスがないことを示します（図3）。同様の形式がGSEでサポートされています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0002 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 1 |
= =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS-Packet 2 (if Length > 2*188) |
= =
| etc. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ULE/SNDU Format for a TS-Packet Payload (D=1)
図3：TSパケットペイロードのULE/SNDU形式（d = 1）
The TS-Concat extension may be used to transport one or more MPEG-2 TS Packets of arbitrary content, interpreted according to [ISO-MPEG2]. One expected use is for the transmission of MPEG-2 SI/PSI signalling [RFC4259].
TS-CONCAT拡張は、[ISO-MPEG2]に従って解釈される任意のコンテンツの1つまたは複数のMPEG-2 TSパケットを輸送するために使用できます。予想される使用の1つは、MPEG-2 Si/PSIシグナル伝達[RFC4259]の伝達です。
NULL TS Packets [ISO-MPEG2] SHOULD NOT be sent using this encapsulation. To reduce transmission overhead and processing, an Encapsulator SHOULD specify a maximum period of time that it can wait before sending all queued TS Packets. This is known as the TS Packing Threshold. This value MUST be bounded and SHOULD be configurable in the Encapsulator. A larger value can improve efficiency, but incurs higher jitter and could increase the probability of corruption. If additional TS Packets are NOT received within the TS Packing Threshold, the Encapsulator MUST immediately send any queued TS Packets.
Null TSパケット[ISO-MPEG2]は、このカプセル化を使用して送信しないでください。トランスミッションのオーバーヘッドと処理を減らすには、エンコープカプレータは、すべてのキューに囲まれたTSパケットを送信する前に待つことができる最大期間を指定する必要があります。これは、TSパッキングしきい値として知られています。この値は制限されている必要があり、エンカプセーターで構成可能である必要があります。値が大きいほど効率が向上する可能性がありますが、ジッターが高くなり、腐敗の可能性が高まる可能性があります。TSパッキングしきい値内で追加のTSパケットが受信されない場合、カプセレータはすぐにキューに囲まれたTSパケットを送信する必要があります。
The use of this format to transfer MPEG-2 clock references (e.g., a Network Clock Reference, NCR) over ULE/GSE framing raises timing considerations at the encapsulation gateway, including the need to update/modify the timing information prior to transmission by the physical layer. These issues are not considered here, but this operation may be simplified in GSE by ensuring that all SNDUs that carry this Extension Header are placed before other data within the BBFrame DataField [GSE].
この形式を使用してMPEG-2クロック参照（例：ネットワーククロックリファレンス、NCR）をULE/GSEフレーミング上に転送すると、カプセル化ゲートウェイでタイミング考慮事項が生じます。物理層。これらの問題はここでは考慮されませんが、この操作は、この拡張ヘッダーを運ぶすべてのSNDUがBBFrame DataField [GSE]内の他のデータの前に配置されるようにすることにより、GSEで簡素化される場合があります。
This document does not specify how TS Packets are to be handled at the Receiver. However, it notes:
このドキュメントでは、TSパケットの処理方法をレシーバーで指定していません。しかし、それは注意してください：
* A Receiver needs to consistently associate all TS Packets in a Stream with one TS Logical Channel (Stream). If an Encapsulator transmits more than one Stream of TS Packets each encapsulated at a different level or with a different NPA address, a Receiver needs to ensure that each is independently demultiplexed as a separate Stream (Section 3.2 [RFC4259]).
* レシーバーは、1つのTS論理チャネル（ストリーム）でストリーム内のすべてのTSパケットを一貫して関連付ける必要があります。カプセレータがTSパケットの複数のストリームを異なるレベルまたは異なるNPAアドレスでカプセル化したTSパケットの複数のストリームを送信する場合、受信者はそれぞれが個別のストリームとして独立して非屈折していることを確認する必要があります（セクション3.2 [RFC4259]）。
* If an Encapsulator transmits service information encapsulated at different levels or with different NPA addresses, the Receivers need to ensure each Stream is related to the corresponding SI table information (if any). A RECOMMENDED way to reduce signaling interactions is to ensure each PID value uniquely identifies a Stream within a TS Multiplex carrying ULE and also any TS Packets encapsulated by a ULE/GSE Stream.
* カプセレータが異なるレベルまたは異なるNPAアドレスでカプセル化されたサービス情報を送信する場合、受信機は各ストリームが対応するSIテーブル情報（ある場合）に関連していることを確認する必要があります。信号相互作用を減らす推奨される方法は、各PID値がULEを運ぶTSマルチプレックス内のストリームと、ULE/GSEストリームによってカプセル化されたTSパケットを一意に識別することです。
The need for consistency in the use of PIDs and the related service information is described in section 4.2 of [RFC4947].
PIDの使用と関連するサービス情報の使用の一貫性の必要性については、[RFC4947]のセクション4.2に記載されています。
The PDU-Concat Extension Header is specified by an IANA-assigned H-Type value of 0x0003 in hexadecimal. This is a Mandatory Next-Header Extension. It enables a sequence of (usually short) PDUs to be sent within a single SNDU Payload.
PDU-CONCAT拡張ヘッダーは、16進数のIANAが割り当てられたH型値0x0003で指定されています。これは、必須のネクストヘッダー拡張機能です。これにより、一連の（通常は短い）PDUを単一のSNDUペイロード内で送信できます。
The base header contains the Length of the entire SNDU. This carries the value of the combined length of all PDUs to be encapsulated, including each set of encapsulation headers. The base header MAY be followed by one or more additional Extension Headers that precede the PDU-Concat Extension Header. These Extension Headers (e.g., a TimeStamp Extension) apply to the composite concatenated PDU.
ベースヘッダーには、SNDU全体の長さが含まれています。これにより、カプセル化ヘッダーの各セットを含む、カプセル化されるすべてのPDUの合計長さの値が含まれます。ベースヘッダーに続いて、PDU-CONCAT拡張ヘッダーに先行する1つ以上の追加の拡張ヘッダーが続く場合があります。これらの拡張ヘッダー（例：タイムスタンプ拡張）は、複合連結PDUに適用されます。
The Extension Header also contains a 16-bit ULE Type field describing the encapsulated PDU, PDU-Concat-Type. Although any Type value specified in the ULE Next-Header Registry (including Extension Header Types) may be assigned to the encapsulated PDU (except the recursive use of a PDU-Concat type), all concatenated PDUs MUST have a common ULE Type (i.e., all concatenated PDUs passed by the network layer must be associated with the same Type value). This simplifies the receiver design, and reduces the transmission overhead for common use cases.
拡張ヘッダーには、カプセル化されたPDU、PDU-CONCATタイプを記述する16ビットULEタイプフィールドも含まれています。ULE Next-Headerレジストリ（拡張ヘッダータイプを含む）で指定された任意のタイプ値は、カプセル化されたPDU（PDU-Concatタイプの再帰的使用を除く）に割り当てられる場合がありますが、すべての連結PDUには共通のULEタイプが必要です（つまり、ネットワークレイヤーによって渡されたすべての連結されたPDUは、同じタイプ値に関連付けられている必要があります）。これにより、受信機の設計が簡素化され、一般的なユースケースの送信オーバーヘッドが減少します。
Each PDU is prefixed by its length in bytes (shown in the following diagrams as PDU-x-Length for the xth PDU). Encapsulated PDUs are of arbitrary length (in bytes) and are not necessarily aligned to 16-bit or 32-bit boundaries within the SNDU (as shown in the figures 4, 5, and 6). The most significant bit of the first byte is reserved, R, and this specification requires that this MUST be set to zero. Receivers MUST ignore the value of the R bit. The length of each PDU MUST be less than 32758 bytes, but will generally be much smaller.
各PDUは、その長さのバイトで前に付けられます（Xth PDUのPDU-X-Lengthとして次の図に示されています）。カプセル化されたPDUは任意の長さ（バイト）であり、必ずしもSNDU内の16ビットまたは32ビットの境界に整列するわけではありません（図4、5、および6に示すように）。最初のバイトの最も重要なビットはR rであり、この仕様ではこれをゼロに設定する必要があります。レシーバーはRビットの値を無視する必要があります。各PDUの長さは32758バイト未満でなければなりませんが、一般にはるかに小さくなります。
When the SNDU header indicates the presence of an SNDU Destination Address field (i.e., D=0 in ULE), a Network Point of Attachment, NPA, field directly follows the fourth byte of the SNDU header. NPA destination addresses are 6 byte numbers, normally expressed in hexadecimal, used to identify the Receiver(s) in a transmission network that should process a received SNDU. When present, the Receiver MUST associate the same specified MAC/NPA address with all PDUs within the SNDU Payload. This MAC/NPA address MUST also be forwarded with each PDU, if required by the forwarding interface.
SNDUヘッダーがSNDU宛先アドレスのフィールド（つまり、uleでd = 0）の存在を示す場合、ネットワークポイントNPAは、SNDUヘッダーの4番目のバイトに直接従います。NPAの宛先アドレスは、通常、16進数で表される6バイト番号で、受信したSNDUを処理する送信ネットワークで受信機を識別するために使用されます。存在する場合、レシーバーは、同じ指定されたMAC/NPAアドレスをSNDUペイロード内のすべてのPDUに関連付ける必要があります。このMAC/NPAアドレスは、転送インターフェイスで要求される場合、各PDUで転送する必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-1-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: ULE/SNDU Format for a PDU-Concat Payload (D=0)
図4：PDU-CONCATペイロードのULE/SNDU形式（d = 0）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|0 0| Length (12b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | PDU-Concat-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-1-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: GSE/SNDU Format for a PDU-Concat Payload (LT=00)
図5：PDU-CONCATペイロードのGSE/SNDU形式（LT = 00）
When the SNDU header indicates the absence of an SNDU Destination Address field (i.e., D=1 in ULE), all encapsulated PDUs MUST be processed as if they had been received without an NPA address.
SNDUヘッダーがSNDU宛先アドレスフィールド（つまり、uLEでd = 1）がないことを示す場合、すべてのカプセル化されたPDUは、NPAアドレスなしで受信されたかのように処理する必要があります。
The value of D in the ULE header indicates whether an NPA/MAC address is in use [RFC4326]. A similar format is supported in GSE (using the LT field).
ULEヘッダーのDの値は、NPA/MACアドレスが使用されているかどうかを示します[RFC4326]。同様の形式がGSEでサポートされています（LTフィールドを使用）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0003 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDU-Concat-Type |R| PDU-1-Length (15b) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= PDU-1 =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| PDU-2-Length (15b) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
= PDU-2 =
| |
More PDUs as required
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ULE/SNDU Format for a PDU-Concat Payload (D=1)
図6：PDU-CONCATペイロードのULE/SNDU形式（d = 1）
To reduce transmission overhead and processing, an Encapsulator SHOULD specify a maximum period of time it will wait before sending a Concatenated PDU. This is known as the PDU Packing Threshold. This value MUST be bounded and SHOULD be configurable in the Encapsulator. A larger value can improve efficiency, but incurs higher jitter and could increase the probability of corruption. If additional PDUs are NOT received within the PDU Packing Threshold, the Encapsulator MUST immediately send all queued PDUs.
トランスミッションのオーバーヘッドと処理を減らすために、エンカプセーターは、連結したPDUを送信する前に待機する最大期間を指定する必要があります。これは、PDUパッキングしきい値として知られています。この値は制限されている必要があり、エンカプセーターで構成可能である必要があります。値が大きいほど効率が向上する可能性がありますが、ジッターが高くなり、腐敗の可能性が高まる可能性があります。PDUパッキングしきい値内で追加のPDUが受信されない場合、カプセレータはすぐにすべてのキューに囲まれたPDUを送信する必要があります。
The Receiver processes this Extension Header by verifying that it supports the specified PDU-Concat Type (unsupported Types MUST be discarded, but the receiver SHOULD record a PDU-Type error [RFC4326]). It then extracts each encapsulated PDU in turn. The Receiver MUST verify the Length of each PDU. It MUST also ensure that the sum of the Lengths of all processed PDUs equals the Length specified in the SNDU base header. A Receiver SHOULD discard the whole SNDU if the total and PDU sizes are not consistent and this event SHOULD be recorded as a PDU-Concat size mismatch error. A receiver MUST NOT forward a partial PDU with an indicated PDU-Length greater than the number of unprocessed bytes remaining in the SNDU payload field.
受信機は、指定されたPDU-CONCATタイプをサポートすることを確認することによりこの拡張ヘッダーを処理します（サポートされていないタイプは破棄する必要がありますが、受信機はPDUタイプエラー[RFC4326]を記録する必要があります）。次に、カプセル化された各PDUを順番に抽出します。受信者は、各PDUの長さを確認する必要があります。また、すべての処理されたPDUの長さの合計が、SNDUベースヘッダーで指定された長さに等しいことを確認する必要があります。合計とPDUのサイズが一貫していない場合、受信者はSNDU全体を廃棄する必要があり、このイベントはPDU-Concatサイズのミスマッチエラーとして記録する必要があります。受信者は、SNDUペイロードフィールドに残っている未処理のバイトの数よりも大きい指定されたPDU長で部分的なPDUを転送してはなりません。
The TimeStamp Extension Header is an Optional Extension Header that permits an Encapsulator to add a TimeStamp field to an SNDU. The TimeStamp Extension Header is specified by the IANA-assigned H-Type value of 257 decimal. This extension is an Optional Extension Header ([RFC4326], Section 5).
Timestamp拡張ヘッダーは、EncapsulatorがSNDUにタイムスタンプフィールドを追加できるようにするオプションの拡張ヘッダーです。タイムスタンプエクステンションヘッダーは、257小数のIANAが割り当てられたH型値によって指定されています。この拡張機能は、オプションの拡張ヘッダー（[RFC4326]、セクション5）です。
This extension is designed to support monitoring and measurement of the performance of a link to indicate the quality of an operational ULE link. This may be useful for GSE links (e.g., where significant complexity exists in the scheduling provided by the lower layers). Possible uses of this extension include:
この拡張機能は、リンクのパフォーマンスの監視と測定をサポートするように設計されており、運用上のULEリンクの品質を示します。これは、GSEリンク（たとえば、下層によって提供されるスケジューリングに大きな複雑さが存在する場合）に役立つ場合があります。この拡張機能の可能な用途には次のものがあります。
* Validation of in-sequence ordering per Logical Channel * Measurement of one-way delay (when synchronized with the sender) * Measurement of PDU Jitter introduced by the link * Measurement of PDU loss (with additional information from sender)
* 論理チャネルごとのシーケンス順序の検証 *一元配置遅延の測定（送信者と同期した場合） *リンクによって導入されたPDUジッターの測定 * PDU損失の測定（送信者からの追加情報を使用）
Figure 7 shows the format of this extension with a HLEN value of 3 indicating a TimeStamp of length 4B with a Type field (there is no implied byte-alignment).
図7は、型フィールドを持つ長さ4Bのタイムスタンプを示す3のHLEN値を持つこの拡張機能の形式を示しています（暗黙のバイトアライメントはありません）。
0 7 15 23 31
+---------------+---------------+---------------+---------------+
| 0x03 | 0x01 | TimeStamp HI |
+---------------+---------------+---------------+---------------+
| TimeStamp LO | Type |
+---------------+---------------+---------------+---------------+
Figure 7: Format of the 32-bit TimeStamp Extension Header
図7：32ビットタイムスタンプ拡張ヘッダーの形式
The extension carries a 32-bit value (TimeStamp HI plus TimeStamp LO). The specified resolution is 1 microsecond. The value therefore indicates the number of 1-microsecond ticks past the hour in Universal Time when the PDU was encapsulated. This value may be earlier than the time of transmission, due for example to Packing, queuing, and other Encapsulator processing. The value is right-justified to the 32-bit field. Systems unable to insert TimeStamps at the specified resolution MUST pad the unused least-significant bits with a value of zero.
拡張機能には32ビット値があります（Timestamp Hi Plus Timestamp Lo）。指定された解像度は1マイクロ秒です。したがって、値は、PDUがカプセル化された普遍的な時期に1マイクロ秒のティック数を1時間過ぎていることを示します。この値は、たとえばパッキング、キューイング、その他のカプセレータ処理など、送信時よりも早い場合があります。値は、32ビットフィールドに右に正義化されます。指定された解像度でタイムスタンプを挿入できないシステムは、ゼロの値で使用されていない最小重要なビットにパッドをパッドする必要があります。
The last two bytes carry a 16-bit Type field that indicates the type of payload carried in the SNDU or the presence of a further Next-Header ([RFC4326], Section 4.4).
最後の2バイトには、SNDUで運ばれるペイロードのタイプまたはさらに次のヘッダーの存在（[RFC4326]、セクション4.4）を示す16ビットタイプフィールドがあります。
Receivers MAY process the TimeStamp when the PDU encapsulation is removed. Receivers that do not implement, or do not wish to process, the TimeStamp Extension MAY skip this Extension Header. Receivers MUST continue to process the remainder of the SNDU, forwarding the encapsulated PDU.
受信者は、PDUのカプセル化が削除されたときにタイムスタンプを処理する場合があります。タイムスタンプ拡張機能がこの拡張ヘッダーをスキップする場合がある、または処理したくない、または処理したくないレシーバー。レシーバーは、カプセル化されたPDUを転送して、SNDUの残りの処理を継続する必要があります。
IANA has assigned three new Next-Header Type values from the IANA ULE Next-Header Registry. These options are defined for specific use cases envisaged by GSE, but are compatible with ULE.
IANAは、IANA ULE Next-Headerレジストリから3つの新しい次のヘッダータイプの値を割り当てました。これらのオプションは、GSEが想定する特定のユースケースに対して定義されていますが、ULEと互換性があります。
The following assignments have been made in this document and registered by IANA:
次の課題はこのドキュメントで行われ、IANAによって登録されています。
Type Name Reference
名前の参照を入力します
2: TS-Concat Section 3.1
3: PDU-Concat Section 3.2
Type Name H-LEN Reference
タイプ名h-lenリファレンス
257: TimeStamp 3 Section 3.3
257：タイムスタンプ3セクション3.3
The TS-Concat Extension is a Mandatory next-type Extension Header, specified in Section 3.1 of this document. The value of this next-header is defined by an IANA assigned H-Type value of 0x0002.
TS-CONCAT拡張機能は、このドキュメントのセクション3.1で指定されている必須の次型拡張ヘッダーです。このネクストヘッダーの値は、0x0002のH型値を割り当てられたIANAによって定義されます。
The PDU-Concat Extension is a Mandatory next-type Extension Header specified in Section 3.2 of this document. The value of this next-header is defined by an IANA assigned H-Type value of 0x0003.
PDU-CONCAT拡張機能は、このドキュメントのセクション3.2で指定されている必須の次型拡張ヘッダーです。このネクストヘッダーの値は、0x0003のH型値を割り当てられたIANAによって定義されます。
The TimeStamp Extension is an Optional next-type Extension Header specified in Section 3.3 of this document. The value of this next-header is defined by an IANA assigned H-Type value of 257 decimal. This documents defines the format for an HLEN value of 0x3.
タイムスタンプ拡張機能は、このドキュメントのセクション3.3で指定されているオプションの次のタイプの拡張ヘッダーです。このネクストヘッダーの値は、257小数のH型値を割り当てられたIANAによって定義されます。このドキュメントは、0x3のHLEN値の形式を定義します。
The authors gratefully acknowledge the inputs, comments, and assistance offered by the members of the DVB-GBS ad hoc group on DVB-S2 encapsulation, in particular contributions on DVB-S2 transmission aspects from Rita Rinaldo, Axel Jahn, and Ulrik De Bie.
著者は、DVB-S2カプセル化に関するDVB-GBSアドホックグループのメンバーが提供するインプット、コメント、および支援、特にRita Rinaldo、Axel Jahn、およびUlrik de BieからのDVB-S2伝播の側面に関する貢献について感謝しています。
Juan Cantillo provided a significant contribution to the informative appendix. The authors thank Christian Praehauser for his insight and contribution on Extension Header processing issues.
Juan Cantilloは、有益な付録に多大な貢献をしました。著者は、拡張ヘッダー処理の問題に関する彼の洞察と貢献について、クリスチャン・プレーハウザーに感謝します。
Security considerations for ULE are described in [RFC4326], and further information on security aspects of using ULE are described in the security considerations of [RFC4259] and [Sec-Req].
ULEのセキュリティ上の考慮事項は[RFC4326]で説明されており、ULEを使用するセキュリティの側面に関するさらなる情報は、[RFC4259]および[sec-req]のセキュリティに関する考慮事項で説明されています。
An attacker that is able to inject arbitrary TS Packets in a ULE or GSE Stream may modify layer 2 signalling information transmitted by the MPEG-2 TS-Concat extension. Since this attack requires access to the link and/or layer 2 equipment, such an attack could also directly attack signalling information sent as native TS Packets (not encapsulated by ULE/GSE). Security issues relating to the transmission and interpretation of layer 2 signalling information (including Address Resolution) within a TS Multiplex are described in [RFC4947]. The use of security mechanisms to protect the MPEG-2 signalling information is discussed by [Sec-Req].
ULEまたはGSEストリームに任意のTSパケットを注入できる攻撃者は、MPEG-2 TS-CONCAT拡張によって送信されるレイヤー2シグナル伝達情報を変更する場合があります。この攻撃にはリンクおよび/またはレイヤー2機器へのアクセスが必要なため、このような攻撃は、ネイティブTSパケット（ULE/GSEによってカプセル化されていない）として送信されるシグナリング情報を直接攻撃することもできます。TSマルチプレックス内のレイヤー2シグナル伝達情報（アドレス解像度を含む）の送信と解釈に関するセキュリティの問題は、[RFC4947]で説明されています。MPEG-2シグナル伝達情報を保護するためのセキュリティメカニズムの使用については、[sec-req]によって説明されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005.
[RFC4326] Fairhurst、G。およびB. Collini-Nocker、「MPEG-2輸送ストリーム（TS）を介したIPデータグラムの送信のための単方向の軽量カプセル化（ULE）」、RFC 4326、2005年12月。
[GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream Encapsulation (GSE) Protocol, "European Telecommunication Standards, Institute (ETSI), 2007.
[GSE] TS 102 606 "デジタルビデオブロードキャスト（DVB）;ジェネリックストリームカプセル化（GSE）プロトコル、ヨーロッパの通信基準、Institute（ETSI）、2007。
[ETSI-S2] EN 302 307, "Digital Video Broadcasting (DVB); Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services, News Gathering and other broadband satellite applications", European Telecommunication Standards Institute (ETSI).
[ETSI-S2] EN 302 307、「デジタルビデオブロードキャスト（DVB）;放送用の第2世代のフレーミング構造、チャネルコーディング、変調システム、インタラクティブサービス、ニュース収集、その他のブロードバンド衛星アプリケーション」、欧州通信標準研究所（ETSI）。
[S2-REQ] Cantillo, J. and J. Lacan, "A Design Rationale for Providing IP Services over DVB-S2 Links", Work in Progress, December 2006.
[S2-Req] Cantillo、J。およびJ. Lacan、「DVB-S2リンクを介してIPサービスを提供するための設計理論的根拠」、2006年12月、進行中の作業。
[Sec-Req] Cruickshank, H., Iyengar, S., and P. Pillai, "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Work in Progress, November 2007.
[Sec-Req] Cruickshank、H.、Iyengar、S。、およびP. Pillai、「単方向の軽量カプセル化（ULE）プロトコルのセキュリティ要件」、2007年11月の作業。
[IEEE-802.3] "Local and metropolitan area networks - Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE 802.3, IEEE Computer Society, (also ISO/IEC 8802-3), 2002.
[IEEE -802.3]「ローカルおよびメトロポリタンエリアネットワーク - 特定の要件パート3：キャリアセンス衝突検出（CSMA/CD）アクセス方法と物理層の仕様を備えた複数アクセス」、IEEE 802.3、IEEEコンピューターソサエティ（ISO/IEC 8802-3）、2002年。
[ISO-MPEG2] ISO/IEC DIS 13818-1:2000, "Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems", International Organization for Standardization (ISO), 2000.
[ISO-MPEG2] ISO/IEC DIS 13818-1：2000、「情報技術、移動写真と関連するオーディオ情報システムの一般的なコーディング」、国際標準化機関（ISO）、2000。
[RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-Nocker, B., and H. Linder, "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
[RFC4259] Montpetit、M.-J.、Fairhurst、G.、Clausen、H.、Collini-Nocker、B。、およびH. Linder、「MPEG-2ネットワークを介したIPデータグラムの送信のフレームワーク」、RFC 4259、2005年11月。
[RFC4947] Fairhurst, G. and M. Montpetit, "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007.
[RFC4947] Fairhurst、G。およびM. Montpetit、「MPEG-2ネットワーク上のIPデータグラムのアドレス解像度メカニズム」、RFC 4947、2007年7月。
This section provides informative background to the network-layer requirements of the second-generation DVB Transmission Specifications. The second-generation waveforms specified by the Digital Video Broadcasting project offer two main enhancements. First, more efficient physical-layer methods that employ higher-order modulation with stronger FEC and permit adaptive coding and modulation response to changes in traffic and propagation conditions. Second, at the link layer, they offer greater flexibility in framing. Support is provided for a range of stream formats including the classical Transport Stream (TS) [RFC4259]. In addition, a new method called Generic Stream (GS) (or the Generic Mode) is supported. A GS can be packetized or continuous and is intended to provide native transport of other network-layer services. One such method is that provided by the Generic Stream Encapsulation (GSE) [GSE].
このセクションでは、第2世代のDVB伝送仕様のネットワーク層要件の有益な背景を提供します。デジタルビデオブロードキャストプロジェクトで指定された第2世代の波形は、2つの主要な拡張機能を提供します。第一に、より強いFECで高次変調を採用し、トラフィックおよび伝播条件の変化に対する適応的なコーディングと変調応答を可能にする、より効率的な物理レイヤー方法。第二に、リンク層では、フレーミングの柔軟性が向上します。サポートは、古典的な輸送ストリーム（TS）[RFC4259]を含むさまざまなストリーム形式の範囲で提供されます。さらに、ジェネリックストリーム（GS）（またはジェネリックモード）と呼ばれる新しいメソッドがサポートされています。GSはパケット化または連続的にでき、他のネットワーク層サービスのネイティブトランスポートを提供することを目的としています。そのような方法の1つは、一般的なストリームカプセル化（GSE）[GSE]によって提供される方法です。
For example, the DVB-S2 [ETSI-S2] transmission link sequentially multiplexes a series of baseband frames (BBFrames). Each BBFrame comprises a fixed-size 10B header and a payload. The payload carries a DataField and uses padding to fill any unused space. A stream comprises a sequence of BBFrames associated with an Input Stream Identifier (ISI) that is carried in the header of each BBFrame. The simplest scheme uses a single stream (with just one ISI value), but multiple streams are permitted. The BBFrames forming a stream may be of variable size (selected from a set of allowed sizes), and must use the same stream format (i.e., TS or GSE). Each stream represents an independent link with independent address resolution [RFC4947].
たとえば、DVB-S2 [ETSI-S2]トランスミッションリンクは、一連のベースバンドフレーム（BBFrames）を順次マルチプレックスします。各BBFrameは、固定サイズの10Bヘッダーとペイロードで構成されています。ペイロードにはデータフィールドがあり、パディングを使用して未使用のスペースを埋めます。ストリームは、各BBFrameのヘッダーに運ばれる入力ストリーム識別子（ISI）に関連付けられたBBFramesのシーケンスで構成されています。最も単純なスキームでは、単一のストリーム（ISI値が1つだけ）を使用しますが、複数のストリームが許可されています。ストリームを形成するBBFramesは、さまざまなサイズ（許可されたサイズのセットから選択された）であり、同じストリーム形式（つまり、TSまたはGSE）を使用する必要があります。各ストリームは、独立したアドレス解像度との独立したリンクを表しています[RFC4947]。
GSE provides functions that are equivalent to those of the Unidirectional Lightweight Encapsulation (ULE) [RFC4326]. It supports the transmission of IP packets and other network-layer protocols. The network-layer interface resembles that of ULE, where it adopts common mechanisms for a Length field, a 16-bit Type field, and support for Extension Headers. As in ULE, GSE permits multiple address formats, indicated by the LT field (functionally equivalent to the D field in ULE). The default addressing mode uses a 6-byte NPA and a suppressed NPA address (functionally equivalent to D=1 in ULE).
GSEは、単方向の軽量カプセル化（ULE）[RFC4326]の関数と同等の機能を提供します。IPパケットやその他のネットワーク層プロトコルの送信をサポートします。ネットワーク層インターフェイスは、ULEのインターフェイスに似ており、長さフィールド、16ビット型フィールド、および拡張ヘッダーのサポートに共通のメカニズムを採用しています。ULEのように、GSEはLTフィールド（ULEのDフィールドに機能的に同等）で示される複数のアドレス形式を許可します。デフォルトのアドレス指定モードでは、6バイトNPAと抑制されたNPAアドレス（機能的にはd = 1に等しい）を使用します。
GSE also provides more flexible fragmentation at the interface to the physical layer (using the S and E flags). This adapts the SNDUs to a variable-sized link-layer frame, and reflects the more complex requirements in terms of fragmentation and assembly that arise when using point-to-multipoint adaptive physical layers. The integrity of a reassembled SNDU is validated using a CRC-32 in the last fragment for the corresponding PDU.
GSEは、物理層への界面でより柔軟な断片化を提供します（SフラグとEフラグを使用）。これにより、Sndusが可変サイズのリンク層フレームに適応し、ポイントツーマルチポイント適応物理レイヤーを使用するときに発生する断片化とアセンブリの観点から、より複雑な要件を反映します。再組み立てされたSNDUの整合性は、対応するPDUの最後のフラグメントのCRC-32を使用して検証されます。
Authors' Addresses
著者のアドレス
Godred Fairhurst School of Engineering, University of Aberdeen, Aberdeen, AB24 3UE UK
アバディーン大学アバディーン大学、AB24 3ue UKのゴッドレッドフェアハースト工学部
EMail: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk/users/gorry
Bernhard Collini-Nocker Department of Computer Sciences, University of Salzburg, Jakob Haringer Str. 2, 5020 Salzburg, Austria
ベルンハルト・コリーニ・ノッカー・コンピューター・サイエンスの部門、ザ・ザ・サルツブルク大学、ヤコブ・ハリンジャーST。2、5020 Salzburg、オーストリア
EMail: bnocker@cosy.sbg.ac.at
URI: http://www.cosy.sbg.ac.at
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。