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.
この文書で指定された拡張ヘッダのフォーマットはULE及び仕様のデジタルビデオ放送（DVB）ファミリーによって定義された第二世代のフレーム構造のための一般的なストリームカプセル化（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）として知られている）一般的なモードのために設計された第二世代のDVB物理層によって提供され、DVB-S2 [ETSI-S2]のための最初のインスタンスにされています。汎用ストリームのための要件は、[S2-REQ]に記載されています。このカプセル化の重要な特性は、このドキュメントの付録で説明されています。 GSEは、ULEが提示するものに共通であり、サブネットワークデータユニット（SNDUs）のために同様の構成を使用するネットワーク・インターフェースを提供する設計思想を維持しています。
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.
最初の拡張ヘッダは、一つ以上の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.
第二の拡張ヘッダは、一つ以上のPDUが同じULE SNDU内で送信されることを可能にします。この方法は、小さなPDUの多数アタッチメント（NPA）アドレスの同じネットワークポイントに向けられている場合のために設計されています。この方法は、（重複MAC層オーバーヘッドを除去することにより）伝送効率を向上させることができます。また、この受信機は、次に1回の操作で複数のPDUをスキップすることができ、SNDUに関連付けられたNPAアドレスを受信するように構成されていない受信機のための処理オーバヘッドを低減することができます。この方法は、一般的な拡張ヘッダとして定義され、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.
第三の拡張ヘッダは、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].
E：GSEで定義された1ビットのフラグフィールド[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.
カプセル化：DVB-SまたはDVB-S2の汎用モードで出力するためのPDUを受信し、（SNDUsとしてここでは知られている）ペイロード単位にこれらをフォーマットネットワークデバイス[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：ジェネリックストリーム。 BBFramesの流れは、共通の入力ストリーム識別子によって識別される、かつMPEG-2 TS形式[ETSI-S2]を使用していません。これは、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]。 BBFramesの配列を使用して送信された一般的なストリームを形成するためにPDUをカプセル化するための方法。このカプセル化フォーマットは同じ拡張フォーマットとULEの基本的な処理ルールを共有し、共通のIANAレジストリを使用しています。
LT: A two-bit flag field defined in GSE [GSE].
LT：GSEで定義された2ビットのフラグフィールド[GSE]。
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).
MPEG2：モーションピクチャーエキスパートグループ（MPEG）によって指定された標準のセット、および国際標準化機構（ISO / IEC 113818から1）[ISO-MPEG2]、およびH.220におけるITU-T（で標準化）。
Next-Header: A Type value indicating an Extension Header [RFC4326].
次ヘッダ：拡張ヘッダ[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]。 13ビットのフィールドは、各TSパケットのヘッダで運ば。これは、TS論理チャネルを識別するTSパケットが属する[ISO-MPEG2]。表のセクションまたは他のペイロードユニットの部分を形成するTSパケットはすべて同じPID値を運ぶ必要があります。すべてのものPID値はNULL TSパケットは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：トランスポートストリーム[ISO-MPEG2]、TSパケットを用いて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パケットの直列に送信されSNDUsに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
ULE、小数未満1536であるタイプフィールド値の拡張ヘッダを示します。このセクションでは、ULEカプセル化のための3つの拡張フォーマットのセットを記述する。 [GSE] RFC 4326ザによって指定されるのと同じセマンティクスを採用タイプフィールドを使用
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].
カプセル化フォーマットは、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.
拡張ヘッダが動作する時にフィールドによって決定された拡張ヘッダーの自然な順序は、あります。多くの用途に適した順序（第1から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-連結方式の拡張ヘッダは16進数で0×0002のIANAによって割り当てられたH型の値で指定されます。これは必須の拡張ヘッダです。
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.
拡張は、ULE SNDU内の1つ以上のMPEG-2 TSパケットを転送するために使用されます。特定SNDUで運ばTSパケット数は、MPEG-2 TS拡張ヘッダに続くペイロードの残りの部分の大きさから決定されます。 SNDUに含まれるTSパケットの数は、従ってある（長さN-10 + D * 6）Nである/ 188、先行する拡張ヘッダに関連付けられたバイトの数MPEG-2 TS-連結方式の拡張（ゼロもし存在いずれもない）、DはDビットの値です。
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-連結方式サイズ不一致エラーとして記録されるべきです。
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は、NPAアドレス[RFC4326]の存在を示す値D = 0とULEのためのこの拡張ヘッダのフォーマットを示す図です。この場合、他の拡張子を持つ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 SNDUsは、最終断片で運ば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-連結方式の拡張は[ISO-MPEG2]によれば、任意のコンテンツの一つ以上のMPEG2 TSパケットを転送するために使用されると解釈されてもよいです。一つの予想される使用は、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].
ULE / GSEフレーミング上MPEG-2クロックリファレンス（例えば、ネットワーク・クロック・リファレンス、NCR）を転送するために、この形式の使用は、によって送信前にタイミング情報を修正/更新する必要性を含む、カプセル化ゲートウェイで考慮タイミング提起します物理層。これらの問題はここでは考慮されていないが、この操作は、この拡張ヘッダを運ぶ全てSNDUsが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関連付ける必要があります。エンカプスレータは、それぞれ異なるレベルまたは異なる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化連結拡張ヘッダは16進数で0x0003のIANAによって割り当てられたH型の値で指定されます。これは必須次-ヘッダー拡張です。これは、（通常短い）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化連結拡張ヘッダの前に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-連結方式タイプを記述する16ビットULEタイプフィールドを含みます。 （拡張ヘッダタイプを含む）ULEネクストヘッダレジストリで指定された任意の型の値が（PDU化連結型の再帰的使用を除いて）カプセル化されたPDUに割り当ててもよいが、全ての連結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は、（x番目のPDUのPDU-X-長さとして以下の図に示されている）バイトで、その長さによって接頭されます。カプセル化されたPDUはバイト単位で任意の長さのものであり（図4、図5、および図6に示すように）必ずしもSNDU内の16ビットまたは32ビット境界に整列していません。最初のバイトの最上位ビットは、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宛先アドレスフィールドの存在を示す場合（すなわち、D = 0 ULEで）、添付ファイルのネットワークポイントは、NPAは、フィールドは、直接SNDUヘッダの4番目のバイトに続きます。 NPAの宛先アドレスは、受信したSNDUを処理すべき伝送ネットワーク内の受信機（複数可）を識別するために使用される通常進数で表現さ6つのバイト数、です。存在する場合、受信側は、SNDUペイロード内のすべてのPDUと同じ指定されたMAC / NPAアドレスを関連付ける必要があります。転送インタフェースによって要求される場合は、この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化連結ペイロードの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：ペイロード（LT = 00）、連結方式PDUのGSE / SNDUフォーマット
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）が存在しないことを示している場合、それらがNPAアドレスなしで受信されたかのように、すべてのカプセル化されたPDUが処理されなければなりません。
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]であるか否かを示します。同様の形式は（LTフィールドを使用して）GSEに支持されています。
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化連結ペイロードの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化連結タイプをサポートしていることを確認することによって、この拡張ヘッダを処理（サポートされていないタイプは破棄されなければならないが、受信機は、PDUタイプのエラー[RFC4326]を記録する必要があります）。次に順番に各カプセル化されたPDUを抽出します。受信機は、各PDUの長さを確認しなければなりません。また、すべての処理されたPDUの長さの和は、SNDUベースヘッダーで指定された長さに等しいことを保証しなければなりません。合計とPDUのサイズが一致しないと、このイベントがPDU化連結サイズの不一致エラーとして記録されるべきかレシーバ全体SNDUを破棄すべきです。受信機は、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).
タイムスタンプ拡張ヘッダは、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は、タイプフィールドと長さ（b）のタイムスタンプを示す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ビットの値（タイムスタンプHIプラスタイムスタンプLO）を運びます。指定された解像度が1マイクロ秒です。値は、従って、PDUがカプセル化されたときに1マイクロ秒の数は世界時に時間を越えティック示します。この値は、パッキングキューイング、および他のエンカプスレータ処理に例えば起因し、送信の時間より早くてもよいです。値は右揃え32ビットのフィールドにあります。指定された解像度MUSTパッドゼロの値を有する未使用の最下位ビットにタイムスタンプを挿入することができないシステム。
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次-ヘッダーレジストリから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
2：TS-連結方式の3.1節3：PDU化連結セクション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-連結方式の拡張は、このドキュメントのセクション3.1で指定された必須の次の型拡張ヘッダ、です。この次ヘッダの値は、0×0002のIANA割り当てられたH-Type値によって定義されます。
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-連結方式の拡張は、このドキュメントのセクション3.2で指定された必須次型拡張ヘッダです。この次ヘッダの値が0x0003のIANA割り当てられたH-Type値によって定義されます。
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小数点以下のIANA割り当てられたH-Type値によって定義されます。この文書は、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.
作者は感謝してリタリナルド、アクセルヤーン、およびUlrikデ・ビエからDVB-S2の伝送面上の特定の貢献でDVB-S2のカプセル化にDVB-GBSアドホックグループのメンバーによって提供される入力、コメント、および援助を、認めます。
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.
フアンCantilloは有益な付録に多大な貢献を提供します。著者は、拡張ヘッダ処理問題に関する彼の洞察力と貢献のためのキリスト教のPraehauserに感謝します。
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]と[秒-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-連結方式の拡張によって送信されたシグナリング情報層2を変更することができます。この攻撃は、リンク及び/又は層2機器へのアクセスを必要とするので、そのような攻撃は、直接（ULE / GSEによってカプセル化されていない）ネイティブTSパケットとして送信されたシグナリング情報を攻撃する可能性があります。 TS多重内の送信及び（アドレス解決を含む）レイヤ2シグナリング情報の解釈に関連するセキュリティ問題は[RFC4947]に記載されています。 MPEG-2シグナリング情報を保護するためのセキュリティメカニズムの使用は、[秒-REQ]で議論されています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]、RFC 4326 "MPEG-2トランスポートストリーム（TS）上のIPデータグラムの送信の一方向軽量カプセル化（ULE）" Fairhurst、G.およびB. Collini-Nocker、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）プロトコル、" 欧州電気通信標準研究所（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）;放送、双方向サービス、ニュースの収集およびその他のブロードバンド衛星アプリケーションのための第二世代のフレーミング構造、チャネル符号化及び変調方式」、欧州電気通信標準協会（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.ラカン、 "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.
[秒-REQ]クルックシャンク、H.、アイアンガー、S.、およびP. Pillaiさん、進歩、2007年11月、作業 "単方向ライト級カプセル化（ULE）プロトコルのためのセキュリティ要件"。
[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コンピュータ学会、（8802また、ISO / IEC -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.リンダー、 "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、RFC 4947、2007年7月 "MPEG-2ネットワーク上でIPデータグラムのための解決メカニズムアドレス"。
Appendix A. The Second-Generation DVB Transmission Specifications
付録A.第二世代DVB伝送仕様
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].
このセクションでは、第二世代のDVB伝送仕様のネットワーク層の要件に有益な背景を提供します。デジタルビデオ放送プロジェクトで指定された第二世代の波形は、主に2つの拡張機能を提供します。より強力なFECと高次変調を使用し、トラフィックおよび伝播条件の変化に適応符号化変調応答を可能にする最初の、より効率的な物理層の方法。第二に、リンク層で、彼らは、フレーミングの柔軟性を提供します。支持体は、古典的なトランスポートストリーム（TS）[RFC4259]を含むストリーム・フォーマットの範囲のために提供されます。また、汎用ストリーム（GS）（またはジェネリックモード）と呼ばれる新しい方法がサポートされています。 GSは、パケットまたは連続および他のネットワーク層サービスのネイティブな輸送を提供することを目的とすることができます。一つのそのような方法は、ジェネリックストリームカプセル化（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ヘッダ及びペイロードを含みます。ペイロードは、DataFieldプロパティを運び、未使用のスペースを埋めるためのパディングを使用しています。ストリームは、各BBFRAMEのヘッダで運ばれている入力ストリーム識別子（ISI）に関連BBFramesの配列を含みます。最も単純な方式は、（一つだけISI値を持つ）単一のストリームを使用するが、複数のストリームが許可されています。ストリームを形成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パケットおよびその他のネットワーク層プロトコルの伝送をサポートしています。ネットワーク層インタフェースは、Lengthフィールド、16ビットのタイプフィールド、および拡張ヘッダーのためのサポートのための共通のメカニズムを採用ULEのものに似ています。 ULEのように、GSEは、LTフィールド（ULEにおけるDフィールドと機能的に同等）で示される複数のアドレス形式を、可能にします。デフォルトのアドレッシングモードは、6バイトのNPAと（ULEでD = 1と機能的に同等な）抑制NPAアドレスを使用します。
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
エンジニアリングのGodred Fairhurst学校、アバディーン、アバディーン大学、AB24 3UE英国
EMail: gorry@erg.abdn.ac.uk URI: http://www.erg.abdn.ac.uk/users/gorry
電子メール：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
ベルンハルトCollini-Nockerコンピュータ科学科、ザルツブルクの大学、ヤコブHaringerのStr。 2、5020ザルツブルク、オーストリア
EMail: bnocker@cosy.sbg.ac.at URI: http://www.cosy.sbg.ac.at
電子メール：URI bnocker@cosy.sbg.ac.at：http://www.cosy.sbg.ac.at
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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に情報を記述してください。