Network Working Group G. Fairhurst
Request for Comments: 4326 University of Aberdeen
Category: Standards Track B. Collini-Nocker
University of Salzburg
December 2005
Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)
MPEG-2トランスポートストリーム（TS）上のIPデータグラムの送信の一方向軽量カプセル化（ULE）
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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
The MPEG-2 Transport Stream (TS) has been widely accepted not only for providing digital TV services, but also as a subnetwork technology for building IP networks.
MPEG-2トランスポートストリーム（TS）が広く、デジタルTVサービスを提供するための、だけでなく、IPネットワークを構築するためのサブネットワーク技術としてだけではなく、受け入れられてきました。
This document describes a Unidirectional Lightweight Encapsulation (ULE) mechanism for the transport of IPv4 and IPv6 Datagrams and other network protocol packets directly over the ISO MPEG-2 Transport Stream as TS Private Data. ULE specifies a base encapsulation format and supports an extension format that allows it to carry additional header information to assist in network/Receiver processing.
この文書では、TSプライベートデータとして直接ISO MPEG-2トランスポートストリーム上のIPv4とIPv6データグラムと他のネットワーク・プロトコル・パケットを輸送するための一方向軽量カプセル化（ULE）メカニズムを説明しています。 ULEは、ベースのカプセル化フォーマットを指定し、ネットワーク/受信機処理を補助する追加のヘッダー情報を搬送することを可能にする拡張フォーマットをサポートします。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Description of the Method .......................................8
4. SNDU Format .....................................................9
4.1. Destination Address Absent (D) Field ......................10
4.2. Length Field ..............................................10
4.3. End Indicator .............................................10
4.4. Type Field ................................................10
4.4.1. Type 1: Next-Header Type Fields ....................11
4.4.2. Type 2: EtherType Compatible Type Fields ...........11
4.5. SNDU Destination Address Field ............................12
4.6. SNDU Trailer CRC ..........................................12
4.7. Description of SNDU Formats ...............................13
4.7.1. End Indicator ......................................14
4.7.2. IPv4 SNDU Encapsulation ............................14
4.7.3. IPv6 SNDU Encapsulation ............................15
5. Extension Headers ..............................................16
5.1. Test SNDU .................................................18
5.2. Bridged Frame SNDU Encapsulation ..........................18
5.3. Extension-Padding Optional Extension Header ...............21
6. Processing at the Encapsulator .................................22
6.1. SNDU Encapsulation ........................................22
6.2. Procedure for Padding and Packing .........................24
7. Receiver Processing ............................................25
7.1. Idle State ................................................26
7.1.1. Idle State Payload Pointer Checking ................26
7.2. Processing of a Received SNDU .............................26
7.2.1. Reassembly Payload Pointer Checking ................28
7.3. Other Error Conditions ....................................28
8. Summary ........................................................29
9. Acknowledgements ...............................................29
10. Security Considerations .......................................29
11. IANA Considerations ...........................................30
11.1. IANA Guidelines ..........................................30
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Appendix A. SNDU Packing Examples .................................35
Appendix B. SNDU Encapsulation ....................................40
This document describes an encapsulation for the transport of IP datagrams, or other network-layer packets, over ISO MPEG-2 Transport Streams [ISO-MPEG2, RFC4259]. The encapsulation satisfies the requirement for a lightweight encapsulation defined in section 4 of [RFC4259]. The basic header provides the required set of protocol fields. Extension headers may also be defined. This header structure is significantly simpler to parse and process [SOOR05] than current alternative methods (e.g., MPE [ETSI-DAT], which builds upon the DSM-CC Table Section syntax [ISO-DSMCC]).
この文書は、ISO MPEG2トランスポート・ストリーム[ISO-MPEG2、RFC4259]の上に、IPデータグラムの輸送のためのカプセル化、または他のネットワーク層パケットを説明します。カプセル化は[RFC4259]のセクション4で定義された軽量のカプセル化のための要件を満たします。基本ヘッダは、プロトコルフィールドの必要なセットを提供します。拡張ヘッダはまた、定義されてもよいです。このヘッダ構造は解析プロセス[SOOR05]現在の代替方法よりも（例えば、DSMCCテーブルセクションシンタックスに基づいて構築MPE [ETSI-DAT]、[ISO-DSMCC]）が大幅に簡単です。
The encapsulation is suited to services based on MPEG-2; for example, the Digital Video Broadcast (DVB) architecture, the Advanced Television Systems Committee (ATSC) system [ATSC, ATSC-G], and other similar MPEG-2-based transmission systems. Such systems provide unidirectional (simplex) physical and link-layer standards. Support has been defined for a wide range of physical media (e.g., Terrestrial TV [ETSI-DVBT, ATSC-PSIP-TC], Satellite TV [ETSI-DVBS, ATSC-S], and Cable Transmission [ETSI-DVBC, ATSC-PSIP-TC]). Bi-directional (duplex) links may also be established using these standards (e.g., DVB defines a range of return channel technologies, including the use of two-way satellite links [ETSI-RCS]) and dial-up modem links [RFC3077].
カプセル化は、MPEG-2に基づくサービスに適しています。例えば、デジタルビデオ放送（DVB）アーキテクチャ、高度テレビジョンシステム委員会（ATSC）システム[ATSC、ATSC-G]、及び他の類似のMPEG-2ベースの伝送システム。このようなシステムは、単一指向性（シンプレックス）物理およびリンク層の規格を提供しています。サポートは、物理メディアの広い範囲（例えば、地上波テレビ[ETSI-DVBT、ATSC-PSIP-TC]、衛星テレビ[ETSI-DVBS、ATSC-S]、およびケーブル伝送[ETSI-DVBC、ATSC-のために定義されていますPSIP-TC]）。双方向（全二重）リンクは、これらの基準を使用して確立することができる（例えば、DVBが双方向衛星リンクの使用を含む、リターンチャネル技術の範囲を定義する[ETSI-RCS]）とダイヤルアップモデムリンク[RFC3077] 。
Protocol Data Units (PDUs), such as Ethernet Frames, IP datagrams, or other network-layer packets, used for transmission over an MPEG-2 Transport Multiplex are passed to an Encapsulator. This formats each PDU into a SubNetwork Data Unit (SNDU) by adding an encapsulation header and an integrity check trailer. The SNDU is fragmented into a series of one or more MPEG-2 Transport Stream (TS) Packets that are sent over a single TS Logical Channel.
イーサネットフレーム、IPデータグラムなどのプロトコルデータユニット（PDU）、またはMPEG-2トランスポート多重を介して送信するために使用される他のネットワーク層パケットは、エンカプスレータに渡されます。これは、カプセル化ヘッダと整合性チェックトレーラーを追加することによって、サブネットワークデータユニット（SNDU）に各PDUをフォーマット。 SNDUは、単一のTS論理チャネルを介して送信される1つ以上のMPEG-2トランスポートストリーム（TS）パケットの系列に断片化されます。
The MPEG-2 specification [ISO-MPEG2] requires that conformant TS Multiplexes provide Program Specific Information (PSI) for each stream in the TS Multiplex. Other MPEG-2-based transmission standards may also define Service Information (SI).
MPEG2仕様[ISO-MPEG2]は準拠TSを多重化は、TS多重における各ストリームのためのプログラム固有情報（PSI）を提供する必要があります。他のMPEG-2ベースの伝送規格は、サービス情報（SI）を定義することができます。
A format_identifier value has been registered for ULE [ULE1]. This 32 bit number has a hexadecimal value of 0x554C4531. Transport Streams that utilise the Programme Map Table (PMT) defined in ISO 13818-1 [ISO-MPEG2] and that use the ULE format defined in this document, SHOULD insert a descriptor with this value in the PMT ES_info descriptor loop. ULE Streams may also be identified by the stream_type value of 0x91 [ATSC-REG] in a SI/PSI Table [ISO_MPEG2].
format_identifier値[ULE1] ULEのために登録されています。この32ビットの数は、0x554C4531の16進数の値を有します。プログラムマップテーブル（PMT）ISO 13818-1で定義されている[ISO-MPEG2]を利用し、それは、この文書で定義されたULE形式を使用するトランスポートストリームは、PMT ES_info記述子ループにこの値を持つ記述子を挿入する必要があります。 ULEストリームはまた、SI / PSIテーブル[ISO_MPEG2]に0x91を[ATSC-REG]ののstream_type値によって識別することができます。
This information may allow Receivers and Re-multiplexors [RFC4259] to locate a specific ULE Stream (i.e., the PID value of the TS Logical
この情報は、受信機および再マルチプレクサ[RFC4259]は特定ULEストリーム（すなわち、論理TSのPID値を検索することを可能にし得ます
Channel that carries a ULE Stream). The conditions under which this information is required and the format in which it is to be provided are beyond the scope of this document. Addressing and mapping issues for ULE over MPEG-2 are also described in [IPDVB-AR].
ULEストリームを運ぶチャネル）。この情報が必要とされる条件とそれが提供されるべき形式は、この文書の範囲を超えています。 MPEG-2上ULEのための問題に対処し、マッピングも[IPDVB-AR]に記載されています。
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書に記載されている大文字のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "オプション" [RFC2119]に記載されているように解釈されるべきです。
Other terms used in this document are defined below:
この文書で使用される他の用語を以下に定義されています。
Adaptation Field: An optional variable-length extension field of the fixed-length TS Packet header, intended to convey clock references and timing and synchronization information as well as stuffing over an MPEG-2 Multiplex [ISO-MPEG2].
アダプテーションフィールド：クロック基準タイミング及び同期情報ならびにMPEG2多重[ISO-MPEG2]上スタッフィングを伝えることを意図固定長のTSパケットヘッダのオプションの可変長拡張フィールド。
AFC: Adaptation Field Control [ISO-MPEG2]. A pair of bits carried in the TS Packet header that signal the presence of the Adaptation Field and/or TS Packet payload.
AFC：適応フィールドコントロール[ISO-MPEG2]。アダプテーションフィールドの存在及び/又はTSパケットペイロードをシグナリングTSパケットヘッダで運ばれたビットの対。
ATSC: Advanced Television Systems Committee [ATSC]. A framework and a set of associated standards for the transmission of video, audio, and data using the ISO MPEG-2 standard.
ATSC：高度テレビジョンシステム委員会[ATSC]。フレームワークおよびISO MPEG-2規格を使用して関連するビデオ、オーディオの伝送のための規格、およびデータのセット。
b: bit. For example, one byte consists of 8b.
B：少し。例えば、1つのバイトは、8bとから構成されています。
B: Byte. Groups of bytes are represented in Internet byte order.
B：バイト。バイトのグループは、インターネットのバイト順で表現されています。
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for transmission of data and control information in an MPEG-2 Private Section, defined by the ISO MPEG-2 standard.
DSMCC：デジタルストレージメディアコマンドおよびコントロール[ISO-DSMCC]。データの伝送のためのフォーマットとは、ISO MPEG-2規格によって定義されたMPEG-2プライベートセクションの情報を、制御します。
DVB: Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) (e.g., [ETSI-DVBC, ETSI-DVBS, ETSI-DVBT]) for the transmission of video, audio, and data using the ISO MPEG-2 Standard [ISO-MPEG2].
DVB：デジタルビデオ放送。フレームワークと欧州電気通信標準化機構（ETSI）によって発行され、関連する標準規格（例えば、[ETSI-DVBC、ETSI-DVBS、ETSI-DVBT]）を使用して、ビデオ、オーディオ、およびデータの伝送のためのISO MPEG-2のセット標準[ISO-MPEG2]。
Encapsulator: A network device that receives PDUs and formats these into Payload Units (known here as SNDUs) for output as a stream of TS Packets.
カプセル化：TSパケットのストリームとして出力するためのPDUを受信し、（SNDUsとしてここでは知られている）ペイロード単位にこれらをフォーマットするネットワーク装置。
End Indicator: A value that indicates to the Receiver that there are no further SNDUs present within the current TS Packet.
終了インジケータ：現在のTSパケット内に存在する一切さらにSNDUsがないことをReceiverに示す値。
LLC: Logical Link Control [ISO-8802-2, IEEE-802.2]. A link-layer protocol defined by the IEEE 802 standard, which follows the Ethernet MAC Header.
LLC：論理リンク制御[ISO-8802-2、IEEE-802.2]。イーサネットMACヘッダに続くIEEE 802規格で定義されたリンク層プロトコル。
MAC: Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]).
MAC：媒体アクセス制御[IEEE-802.3]。 IEEE 802.3規格（またはイーサネットV2 [DIX]による）によって定義されるリンク層プロトコル。
MAC Header: The link-layer header of the IEEE 802.3 standard [IEEE-802.3] or Ethernet v2 [DIX]. It consists of a 6B destination address, 6B source address, and 2B Type field (see also NPA, LLC).
MACヘッダ：IEEE 802.3標準[IEEE-802.3]のリンク層ヘッダ又はイーサネットV2 [DIX]。なお、図6（b）宛先アドレス、（b）ソースアドレス、および（b）タイプフィールド（NPA、LLCも参照）から構成されています。
MPE: Multiprotocol Encapsulation [ETSI-DAT, ATSC-DAT, ATSC-DATG]. A scheme that encapsulates PDUs, forming a DSM-CC Table Section. Each Section is sent in a series of TS Packets using a single TS Logical Channel.
MPE：マルチプロトコルカプセル化[ETSI-DAT、ATSC-DAT、ATSC-DATG]。 DSM-CCテーブルのセクションを形成し、PDUをカプセル化する仕組み。各セクションは、単一のTS論理チャネルを使用してTSパケットの直列に送信されます。
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG) and standardized by the International Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222 [ITU-H222]).
MPEG2：国際標準化機構（ISO / IEC 13818-1）[ISO-MPEG2]でモーション・ピクチャー・エキスパート・グループ（MPEG）で指定し、標準化標準のセット、およびITU H.222でのITU-T（[ -H222]）。
Next-Header: A Type value indicating an Extension Header.
次ヘッダ：拡張ヘッダを示すタイプ値。
NPA: Network Point of Attachment. In this document, refers to a 6-byte destination address (resembling an IEEE MAC address) within the MPEG-2 transmission network that is used to identify individual Receivers or groups of Receivers.
NPA：添付ファイルのネットワークポイント。この文書では、個々の受信機又は受信機のグループを識別するために使用されるMPEG-2伝送ネットワーク内（IEEE MACアドレスに類似）、6バイトの宛先アドレスを参照。
Packing Threshold: A period of time an Encapsulator is willing to defer transmission of a partially filled TS-Packet to accumulate more SNDUs, rather than use Padding. After the Packet Threshold period, the Encapsulator uses Padding to send the partially filled TS-Packet.
パッキングしきい値：エンカプスレータはむしろ使用パディングよりも、より多くのSNDUsを蓄積するために部分的に充填されたTS-パケットの送信を延期する意思がある期間。パケットスレッシュホールド期間の後、エンキャプは、部分的に満たされたTS-パケットを送信するためにパディングを使用しています。
Padding: A method that fills the remaining unused bytes in a TS Packet payload using the specific pattern of 0xFF.
パディング：0xFFでの特定のパターンを使用して、TSパケットペイロード内の残りの未使用バイトを充填方法。
Payload Unit, PU. A sequence of bytes sent using a TS. Examples of Payload Units include: an MPEG-2 Table Section or a ULE SNDU.
ペイロードユニット、PU。 TSを使用して送信されたバイトのシーケンス。ペイロードユニットの例としては、MPEG-2テーブルセクションまたはULE SNDUを。
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets.
PDU：プロトコルデータユニット。 PDUの例は、イーサネットフレーム、IPv4またはIPv6データグラム、および他のネットワークパケットを含みます。
PES: Packetized Elementary Steam [ISO-MPEG2]. A format of MPEG-2 TS packet payload usually used for video or audio information.
PES：パケット化基本スチーム[ISO-MPEG2]。 MPEG-2 TSパケットペイロードのフォーマットは、通常ビデオまたは音声情報のために使用されます。
PID: Packet Identifier [ISO-MPEG2]. A 13-bit field carried in the header of TS Packets. This is used to identify the TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets
PID：パケット識別子[ISO-MPEG2]。 TSパケットのヘッダで運ばれた13ビットのフィールド。これは、TSパケットは[ISO-MPEG2]属するTS論理チャネルを識別するために使用されます。 TSパケット
forming the parts of a Table Section, PES, or other Payload Unit must all carry the same PID value. The all-zeros PID 0x0000 as well as other PID values are reserved for specific PSI/SI Tables [ISO-MPEG2]. The all-ones PID value 0x1FFF 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.
表セクション、PES、または他のペイロード・ユニットの一部を形成するすべて同じPID値を運ばなければなりません。すべてゼロのPIDが0x0000の、ならびに他のPID値は、特定のPSI / SIテーブル[ISO-MPEG2]のために予約されています。すべてのものPID値0x1FFFのはNULL TSパケットはTS多重の固定ビットレートを維持するために導入示します。別のTSを多重化を使用して送信TS論理チャネルのために使用されたPID値の間に必要な関係はありません。
PP: Payload Pointer [ISO-MPEG2]. An optional one-byte pointer that directly follows the 4-byte TS Packet header. It contains the number of bytes that follow the Payload Pointer, up to the start of the first Payload Unit (counted from the first byte of the TS Packet payload field, and excluding the PP field itself). The presence of the Payload Pointer is indicated by the value of the PUSI bit in the TS Packet header. The Payload Pointer is present in DSM-CC, Table Sections, and ULE. It is not present in TS Logical Channels that use the PES-format.
PP：ペイロードのポインタ[ISO-MPEG2]。直接4バイトのTSパケットヘッダに続くオプションの一バイトのポインタ。これは、最初のペイロード・ユニット（TSパケットペイロードフィールドの最初のバイトから数え、及びPPフィールド自体を除く）の開始まで、ペイロードポインタをたどるバイトの数を含んでいます。ペイロードポインタの存在は、TSパケットヘッダにおけるPUSIビットの値によって示されます。ペイロードのポインタは、DSM-CC、テーブルセクション、およびULEに存在しています。これは、PES-形式を使用するTS論理チャネルには存在しません。
Private Section: A syntactic structure constructed in accordance with Table 2-30 of [ISO-MPEG2]. The structure may be used to identify private information (i.e., not defined by [ISO-MPEG2]) relating to one or more elementary streams, or a specific MPEG-2 program, or the entire Transport Stream. Other Standards bodies, e.g., ETSI, ATSC, have defined sets of table structures using the private_section structure. A Private Section is transmitted as a sequence of TS Packets using a TS Logical Channel. A TS Logical Channel may carry sections from more than one set of tables.
プライベートセクション：[ISO-MPEG2]の表2-30に従って構成統語構造。構造は、1つ以上のエレメンタリストリーム、または特定のMPEG2プログラム、または全トランスポートストリームに関連する個人情報を（すなわち、[ISO-MPEG2]によって定義されていない）を識別するために使用することができます。他の標準化団体、例えば、ETSI、ATSCは、private_section構造を使用してテーブル構造のセットを定義しています。プライベートセクションは、TS論理チャネルを使用してTSパケットのシーケンスとして送信されます。 TS論理チャネルは、テーブルの複数のセットからのセクションを運ぶことができます。
PSI: Program Specific Information [ISO-MPEG2]. Tables used to convey information about the service carried in a TS Multiplex. The information is carried in one of four specifically identified Table Sections defined by MPEG-2 [ISO-MPEG2]. See also SI Table.
PSI：プログラムスペシフィックインフォメーション[ISO-MPEG2]。テーブルは、TS多重で運ばサービスに関する情報を伝達するために使用されます。情報は、MPEG2 [ISO-MPEG2]によって定義された4つの具体的に識別されたテーブルセクションのいずれかに搬送されます。 SI表も参照してください。
PU: Payload Unit.
PU：ペイロードユニット。
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG2]. A single-bit flag carried in the TS Packet header. A PUSI value of zero indicates that the TS Packet does not carry the start of a new Payload Unit. A PUSI value of one indicates that the TS Packet does carry the start of a new Payload Unit. In ULE, a PUSI bit set to 1 also indicates the presence of a one-byte Payload Pointer (PP).
PUSI：Payload_Unit_Start_Indicator [ISO-MPEG2]。 TSパケットヘッダで運ば単一ビットのフラグ。ゼロのPUSI値は、TSパケットが新しいペイロードユニットの開始を運ばないことを示しています。 1のPUSI値は、TSパケットが新しいペイロードユニットの開始を携帯していることを示しています。 ULEに、PUSIは、1バイトのペイロード・ポインタ（PP）の存在を示すビットを1に設定します。
Receiver: Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer).
受信機：TSマルチプレックスからの信号を処理して（リンク層で動作しているとき、またはブリッジモジュール）ネットワーク層サービスにカプセル化されたPDUのフィルタリングおよび転送を行う機器。
SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is defined by another standards body to convey information about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections; however, all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2].
SI表：サービス情報テーブル[ISO-MPEG2]。この文書では、この用語は、TS多重で運ばサービスに関する情報を伝えるために、他の標準化団体によって定義されたテーブルを説明します。表は、一つ以上のテーブルセクションから構成されてもよいです。しかし、特定のSI表のすべてのセクションでは、論理チャネル[ISO-MPEG2]単一TS上で実行されなければなりません。
SNDU: SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU：サブネットワークデータユニット。 MPEG-2ペイロード・ユニットとして送信されるカプセル化されたPDU。
Table Section: A Payload Unit carrying all or part of an SI or PSI Table [ISO-MPEG2].
テーブル部：SIやPSIテーブル[ISO-MPEG2]の全て又は一部を運ぶペイロードユニット。
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. See also TS Logical Channel and TS Multiplex.
TS：トランスポートストリーム[ISO-MPEG2]、TSパケットを用いてMPEG2レベルで伝送方法。それはISO / OSI参照モデルのレイヤ2を表します。また、論理チャネルとTS多重化するTSを参照してください。
TS Header: The 4-byte header of a TS Packet [ISO-MPEG2]. Each 188B TS Packet incorporates a 4B header with the following fields (those referenced within this document are marked with *):
TSヘッダ：TSパケットの4バイトのヘッダ[ISO-MPEG2]。各188B TSパケットは、次のフィールド（このドキュメント内で参照ものは*でマークされている）と4Bヘッダーが組み込まれています。
Field Length Name/Purpose
(in bits)
8b Synchronisation pattern equal to 0x47 *1b Transport Error Indicator *1b Payload Unit Start Indicator (PUSI) 1b Transport Priority *13b Packet IDentifier (PID) 2b Transport Scrambling Control *2b Adaptation Field Control (AFC) *4b Continuity Counter (CC)
0x47に等しい8bを同期パターン* 1bのトランスポートエラーインジケータ* 1bのペイロードユニットスタートインジケータ（PUSI）1bのトランスポート優先* 13bはパケット識別子（PID）2bのトランスポートスクランブル制御* 2bの継続カウンター4bのアダプテーションフィールドコントロール（AFC）*（CC）
If the PUSI bit is set to a value of 1, there is one additional field following the TS packet header:
PUSIビットが1の値に設定されている場合、TSパケットヘッダに続く一つの追加フィールドがあります。
*8b Payload Pointer (PP)
* 8Bペイロードポインタ（PP）
TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO-MPEG2]. It exists at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value (this value is unique within a specific TS Multiplex). The term "Stream" is defined in MPEG-2 [ISO-MPEG2] to describe the content carried by a specific TS Logical Channel (see ULE Stream). Some PID values are reserved (by MPEG-2) for specific signalling. Other standards (e.g., ATSC, DVB) also reserve specific PID values.
TS論理チャネル：トランスポート・ストリーム論理チャネル。この文書では、この用語は、MPEG2レベル[ISO-MPEG2]のチャネルを識別する。これは、ISO / OSI参照モデルのレベル2に存在します。 TS論理チャネルを介して送信されるすべてのパケットは、（この値は、特定のTSマルチプレックス内で一意である）同じPID値を運びます。用語「ストリーム」は、特定のTSの論理チャネル（ULEストリームを参照）によって運ばれるコンテンツを記述するためにMPEG2 [ISO-MPEG2]で定義されています。いくつかのPID値は、特定のシグナリングのために（MPEG-2）予約されています。他の規格（例えば、ATSC、DVB）は、特定のPID値を留保します。
TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower-layer connection. This may be a common physical link (i.e., a transmission at a specified symbol rate, FEC setting, and transmission frequency) or an encapsulation provided by another protocol layer (e.g., Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly associated with a different PID value) [RFC4259]; for example, to redistribute the same multicast content to two terrestrial TV transmission cells.
TS多重：この文書では、この用語は、MPEG-2 TS単下位層接続を介して送信される論理チャネルのセットを定義します。これは、共通の物理リンク（すなわち、指定されたシンボルレート、FEC設定、送信周波数で送信）、または別のプロトコル層（例えば、イーサネット（登録商標）、又はIPオーバーRTP）によって提供されるカプセルであってもよいです。同じTS論理チャネルは、（おそらく異なるPID値に関連付けられた）複数のTS多重[RFC4259]の上に繰り返されてもよいです。例えば2つの地上波TV送信セルに同一のマルチキャストコンテンツを再配布します。
TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header, plus optional overhead including an Adaptation Field, encryption details, and time stamp information to synchronise a set of related TS Logical Channels.
TSパケット：TS多重[ISO-MPEG2]を介して送信されるデータの固定長188Bユニット。各TSパケットは、TS関連する論理チャネルのセットを同期するために、図4（b）ヘッダに加え、アダプテーションフィールドを含む任意のオーバーヘッド、暗号化の詳細、およびタイムスタンプ情報を運びます。
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [ISO-MPEG2].
ULEストリーム：MPEG-2 TSのみULEは、PDUをカプセル化運ぶ論理チャネル。 ULEストリームはSI / PSI [ISO-MPEG2]中のstream_typeの定義によって同定することができます。
PDUs (IP packets, Ethernet frames or packets from other network protocols) are encapsulated to form a Subnetwork Data Unit (SNDU). The SNDU is transmitted over an MPEG-2 transmission network either by being placed in the payload of a single TS Packet, or, if required, by being fragmented into a series of TS Packets. Where there is sufficient space, the method permits a single TS Packet to carry more than one SNDU (or part thereof), a practice sometimes known as Packing. All TS Packets comprising an SNDU MUST be assigned the same PID, and therefore form a part of the same TS Logical Channel.
PDU（IPパケット、イーサネットフレーム、または他のネットワークプロトコルからのパケット）がサブネットワークデータユニット（SNDU）を形成するためにカプセル化されます。 SNDUは、MPEG-2伝送ネットワークを介してのいずれかで必要に応じてTSパケットの系列に断片化されることにより、一つのTSパケットのペイロードに配置され、又はされて伝送されます。十分なスペースがある場合、この方法は、複数のSNDU（またはその一部）、時々パッキングとして知られている練習を運ぶために単一のTSパケットを許可します。 SNDUを備えたすべてのTSパケットは、同一PID割り当てられ、したがって同じTSの一部の論理チャネルを形成しなければなりません。
The ULE encapsulation is limited to TS private streams only. The header of each TS Packet carries a one-bit Payload Unit Start Indicator (PUSI) field. A PUSI field with a value of 1 indicates the start of at least one Payload Unit (SNDU) within the TS Packet payload. The semantics of the PUSI bit are defined for PES and PSI packets [ISO-MPEG2]; for private data, its use is not defined in the MPEG-2 Standard. Although ULE uses private data, the operation follows that of PSI packets. Hence, the following PUSI values are defined:
ULEカプセル化は、プライベートストリームのみをTSに限定されています。各TSパケットのヘッダは、1ビットのペイロードユニットスタートインジケータ（PUSI）フィールドを運びます。 1の値を持つPUSIフィールドは、TSパケットペイロード内の少なくとも一つのペイロード・ユニット（SNDU）の開始を示します。 PUSIビットの意味は[ISO-MPEG2] PESとPSIパケットのために定義されています。プライベートデータのために、その使用はMPEG-2規格で定義されていません。 ULEは、プライベートデータを使用していますが、操作はPSIパケットのそれに従います。したがって、以下のPUSI値が定義されています。
0: The TS Packet does NOT contain the start of an SNDU, but
contains the continuation, or end, of an SNDU;
1: The TS Packet contains the start of an SNDU, and a one byte Payload Pointer follows the last byte of the TS Packet header.
1：TSパケットは、SNDUの開始を含み、1バイトのペイロードポインタは、TSパケットヘッダの最後のバイトに続きます。
If a Payload Unit (SNDU) finishes before the end of a TS Packet payload, but it is not intended to start another Payload Unit, a stuffing procedure (known as Padding) fills the remainder of the TS Packet payload with bytes with a value 0xFF [ISO-MPEG2].
ペイロード・ユニット（SNDU）をTSパケットペイロードの終了前に終了するが、別のペイロード・ユニット、（パディングとして知られている）スタッフィング手順を開始することを意図していない場合、値は0xFFとバイトとTSパケットペイロードの残りを埋めます[ISO-MPEG2]。
A Receiver processing MPEG-2 Table Sections that receives a value of 0xFF in the first byte of a Table Section (table_Id) interprets this as Padding/Stuffing and silently discards the remainder of the TS Packet payload. The payload of the next TS Packet for the same TS Logical Channel will begin with a Payload Pointer of value 0x00, indicating that the next Payload Unit immediately follows the TS Packet header. The ULE protocol resembles this, but differs in the exact procedure (see the following sections).
表セクション（TABLE_ID）の最初のバイトには0xFFの値を受信する受信処理MPEG-2テーブルセクションは、パディング/スタッフィングとしてこれを解釈し、サイレントTSパケットペイロードの残りを破棄する。同じTS論理チャネルのための次のTSパケットのペイロードには、次のペイロード・ユニットがすぐにTSパケットヘッダの後に続くことを示し、値0×00のペイロードポインタで開始します。 ULEプロトコルはこれを似ているが、正確な手順（以下のセクションを参照）が異なります。
The TS Packet Header also carries a two-bit Adaptation Field Control (AFC) value. This adaptation field may extend the TS Packet Header to carry timing and synchronisation information and may also be used to include stuffing bytes before a TS Packet payload. Adaptation Field stuffing is NOT used in this encapsulation method, and TS Packets from a ULE Encapsulator MUST be sent with an AFC value of '01'. For TS Logical Channels supporting ULE, Receivers MUST discard TS Packets that carry other AFC values.
TSパケットヘッダは、2ビット適応フィールド制御（AFC）値を運びます。このアダプテーションフィールドは、タイミング及び同期情報を搬送するTSパケットヘッダを延長することができるし、またTSパケットペイロードの前にスタッフィングバイトを含むために使用されてもよいです。アダプテーションフィールドスタッフィングは、このカプセル化方法で使用されていない、およびULEエンカプスレータからTSパケットが「01」のAFC値と送らなければなりません。 TS論理チャネルがULEをサポートするために、レシーバは、他のAFC値を運ぶTSパケットを捨てなければなりません。
PDUs are encapsulated using ULE to form an SNDU. (Each SNDU is an MPEG-2 Payload Unit.) The encapsulation format to be used for PDUs is illustrated below:
PDUは、SNDUを形成するために、ULEを使用してカプセル化されます。 （各SNDUは、MPEG-2ペイロード・ユニットである。）のPDUのために使用されるカプセル化フォーマットを以下に示します。
< ----------------------------- SNDU ----------------------------- >
+-+-------------------------------------------------------+--------+
|D| Length | Type | Dest Address* | PDU | CRC-32 |
+-+-------------------------------------------------------+--------+
Figure 1: SNDU Encapsulation (* optional Destination Address)
図1：SNDUカプセル化（*オプションの宛先アドレス）
All multi-byte values in ULE (including the Length/End Indicator (4.2,4.3), Type (4.4), Destination Address (4.5), and Extension Headers (5)) are transmitted in network byte order (most significant byte first). The most significant bit of each byte is placed in the left-most position of the 8-bit field. Appendix A provides informative examples of usage.
（長さ/終了インジケーター（4.2,4.3）、タイプ（4.4）、宛先アドレス（4.5）、および拡張ヘッダーを含む（5））ULEのすべてのマルチバイト値は、ネットワークバイト順（最上位バイトが最初）に送信され、 。各バイトの最上位ビットは、8ビット・フィールドの一番左の位置に配置されます。付録Aは、使用の有益な例を示します。
The most significant bit of the Length field carries the value of the Destination Address Absent Field, the D-bit. A value of 0 indicates the presence of the Destination Address Field (see section 4.5). A value of 1 indicates that a Destination Address Field is not present.
Lengthフィールドの最上位ビットは、宛先アドレス不在フィールド、Dビットの値を運びます。 0の値は、宛先アドレスフィールドの存在を示す（セクション4.5を参照）。 1の値は、宛先アドレスフィールドが存在しないことを示しています。
An End Indicator (4.3) MUST be sent with a D-bit value of 1. Other SNDUs MAY be sent with a D-bit value of 0 or 1. The default method SHOULD use a D-bit value of 0 (see section 4.5).
終了インジケータ（4.3）は、デフォルトの方法は、0のDビット値を使用する必要が0または1のDビットの値を用いて送信することができる1その他SNDUsのDビット値で送らなければなりません（セクション4.5を参照）。
A 15-bit value that indicates the length, in bytes, of the SNDU counted from the byte following the Type field of the SNDU base header (figure 9) up to and including the CRC. This Length includes the size of any extension headers that may be present (section 5). Note the special case described in section 4.3.
SNDUのバイト単位の長さを示す15ビットの値は、SNDU基本ヘッダのタイプフィールド（図9）およびCRCを含むまで続くバイトから数えました。この長さは、存在し得る任意の拡張ヘッダのサイズ（セクション5）を含みます。 4.3節で説明した特殊なケースに注意してください。
When the first two bytes following an SNDU have the value 0xFFFF, this denotes an End Indicator (i.e., all ones length combined with a D-bit value of 1). This indicates to the Receiver that there are no further SNDUs present within the current TS Packet (see section 6), and that no Destination Address Field is present. The value 0xFF has specific semantics in MPEG-2 framing, where it is used to indicate the presence of Padding. This use resembles [ISO-DSMCC].
SNDU後の最初の2つのバイトは、値が0xFFFFを有する場合、これは、エンド・インジケータ（1のDビット値と結合すなわち、すべてのものは長さ）です。これは、現在のTSパケット（セクション6を参照）内に存在するさらなるSNDUsがないことをレシーバに示し、およびNO宛先アドレスフィールドが存在しないこと。値は0xFFは、パディングの存在を示すために使用されるMPEG-2フレーミング、内の特定の意味を有します。この使用似ている[ISO-DSMCC]。
The 16-bit Type field indicates the type of payload carried in an SNDU, or the presence of a Next-Header. The set of values that may be assigned to this field is divided into two parts, similar to the allocations for Ethernet.
16ビットのタイプフィールドはSNDUで運ばれるペイロードのタイプ、または次のヘッダの存在を示します。このフィールドに割り当てることができる値のセットは、イーサネットのために割り当てと同様二つの部分に分割されます。
EtherTypes were originally specified by Xerox under the Ethernet v2 Specification [DIX]. After specification of IEEE 802.3 [IEEE-802.3, ISO-8802-2], the set of EtherTypes less than 1536 (0x0600) assumed the role of a length indicator. Ethernet receivers use this feature to discriminate LLC format frames. Hence, any IEEE EtherType < 1536 indicates an LLC frame, and the actual value indicates the length of the LLC frame.
EtherTypeにはもともとイーサネットv2の仕様[DIX]の下ゼロックスで指定されました。 IEEE 802.3 [IEEE-802.3、ISO-8802-2]、1536（0x0600）未満のEtherTypeのセットの指定した後、長さインジケータの役割を仮定しました。イーサネット受信機は、LLC形式のフレームを識別するために、この機能を使用しています。したがって、任意のIEEEのEtherType <1536 LLCフレームを示しており、実際の値は、LLCフレームの長さを示します。
There is a potential ambiguous case when a Receiver receives a PDU with two Length fields: The Receiver would need to validate the actual length and the Length field and ensure that inconsistent values are not propagated by the network. Specification of two independent Length fields is therefore undesirable. In the ULE header, this is avoided in the SNDU header by including only one length value, but bridging of LLC frames re-introduces this consideration (section 5.2).
レシーバは、2つの長さフィールドでPDUを受信した可能性のある曖昧な場合があります：レシーバは、実際の長さと長さフィールドを検証し、一貫性のない値がネットワークによって伝播されないことを確認する必要があります。二つの独立した長さフィールドの指定は好ましくない。 ULEヘッダで、これは1つの長さ値を含むが、再発表をLLCフレームからこの考察（セクション5.2）を架橋することによりSNDUヘッダーに回避されます。
The Ethernet LLC mode of identification is not required in ULE, since the SNDU format always carries an explicit Length field, and therefore the procedure in ULE is modified, as below:
SNDUフォーマットは以下のように、常に明示的な長さフィールドを運び、したがってULEの手順が変更されるので、識別のイーサネットLLCモードは、ULEに必要とされません。
The first set of ULE Type field values comprise the set of values less than 1536 in decimal. These Type field values are IANA assigned (see section 4.4.1) and indicate the Next-Header.
ULEタイプフィールド値の最初のセットは、小数で1536未満の値のセットを含みます。これらのタイプフィールド値はIANAが割り当てられた（セクション4.4.1を参照）、次に、ヘッダを示しています。
The second set of ULE Type field values comprise the set of values greater than or equal to 1536 in decimal. In ULE, this value is identical to the corresponding type codes specified by the IEEE/DIX type assignments for Ethernet and recorded in the IANA EtherType registry.
ULE Typeフィールドの値の第2セットは、より大きい又は小数で1536に等しい値のセットを含みます。 ULEでは、この値はイーサネットIEEE / DIX型割り当てによって指定され、IANAのEtherTypeレジストリに記録された対応するタイプコードと同一です。
The first part of the Type space corresponds to the values 0 to 1535 decimal. These values may be used to identify link-specific protocols and/or to indicate the presence of Extension Headers that carry additional optional protocol fields (e.g., a bridging encapsulation). Use of these values is co-ordinated by an IANA registry. The following types are defined in this document:
タイプ空間の最初の部分は、1535 10進数の値0に相当します。これらの値は、リンク固有のプロトコルを識別するために、および/または追加のオプションのプロトコルフィールド（例えば、ブリッジカプセル化）を運ぶ拡張ヘッダの存在を示すために使用されてもよいです。これらの値の使用は、IANAレジストリでコーディネートされています。次のタイプは、この文書で定義されています。
0x0000: Test SNDU (see section 5.1)
0x0001: Bridged Frame (see section 5.2)
0x0100: Extension-Padding (see section 5.3)
The remaining values within the first part of the Type space are reserved for Next-Header values allocated by the IANA.
タイプ空間の最初の部分内の残りの値は、IANAによって割り当てられたネクストヘッダ値のために予約されています。
The second part of the Type space corresponds to the values between 0x600 (1536 decimal) and 0xFFFF. This set of type assignments follows DIX/IEEE assignments (but excludes use of this field as a frame length indicator). All assignments in this space MUST use the values defined for IANA EtherType. The following two Type values are used as examples (taken from the IANA EtherTypes registry):
タイプ空間の第2の部分は、0x600（1536年10進数）と0xFFFFの間の値に相当します。タイプの割り当てのこのセットは、DIX / IEEE割り当てを以下の（しかし、フレーム長インジケータとしてこのフィールドの使用を除きます）。このスペース内のすべての割り当てはIANAのEtherTypeに定義されている値を使用しなければなりません。次の二つのタイプ値は（IANAのEtherTypeレジストリから採取した）例として使用されます。
0x0800: IPv4 Payload (see section 4.7.2)
0x86DD: IPv6 Payload (see section 4.7.3)
The SNDU Destination Address Field is optional (see section 4.1). This field MUST be carried (i.e., D=0) for IP unicast packets destined to routers that are sent using shared links (i.e., where the same link connects multiple Receivers). A sender MAY omit this field (D=1) for an IP unicast packet and/or multicast packets delivered to Receivers that are able to utilise a discriminator field (e.g., the IPv4/IPv6 destination address, or a bridged MAC destination address), which, in combination with the PID value, could be interpreted as a Link-Level address.
SNDUの宛先アドレスフィールドはオプションです（4.1節を参照してください）。このフィールドは、（同じリンクが複数の受信機を接続する、すなわち、）共有リンクを使用して送信されるルータ宛のIPユニキャストパケットのために（すなわち、D = 0）実行されなければなりません。送信側は、このフィールドを省略は、（D = 1）IPユニキャストパケットおよび/またはディスクリミネータ・フィールドを利用することができる受信機に配信されるマルチキャストパケット（例えば、IPv4の/ IPv6宛先アドレス、または架橋MAC宛先アドレス）、これは、PID値との組み合わせで、リンクレベルのアドレスとして解釈できます。
When the SNDU header indicates the presence of an SNDU Destination Address field (i.e., D=0), 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 MPEG-2 transmission network that should process a received SNDU. The value 0x00:00:00:00:00:00 MUST NOT be used as a destination address in an SNDU. The least significant bit of the first byte of the address is set to 1 for multicast frames, and the remaining bytes specify the link-layer multicast address. The specific value 0xFF:FF:FF:FF:FF:FF is the link broadcast address, indicating that this SNDU is to be delivered to all Receivers.
SNDUヘッダはSNDU宛先アドレスフィールド（すなわち、D = 0）の存在を示す場合、添付のネットワークポイント（NPA）フィールドを直接SNDUヘッダの4番目のバイトに続きます。 NPAの宛先アドレスは、受信したSNDUを処理するMPEG-2伝送ネットワーク内の受信機（複数可）を識別するために使用される通常進数で表現さ6つのバイト数、です。値0×00：00：00：00：00：00 SNDUの宛先アドレスとして使用してはいけません。アドレスの最初のバイトの最下位ビットは、マルチキャストフレームのために1に設定され、残りのバイトは、リンク層マルチキャストアドレスを指定します。具体的な値は0xFF：FF：FF：FF：FF：FFこのSNDUは、すべての受信機に配信されることを示す、リンクのブロードキャストアドレスです。
IPv4 packets carrying an IPv4 subnetwork broadcast address need to be delivered to all systems with the same network prefix. When a SNDU Destination Address is present (D=0), the value MUST be set to the NPA link broadcast address (0xFF:FF:FF:FF:FF:FF).
IPv4のサブネットブロードキャストアドレスを持つIPv4パケットは、同じネットワークプレフィックスを持つすべてのシステムに配信する必要があります。 SNDU宛先アドレスが（D = 0）が存在する場合、値がNPAリンクブロードキャストアドレス（：FF：FF：FF：FF：FFは0xFF）を設定しなければなりません。
When the PDU is an IP multicast packet and an SNDU Destination Address is present (D=0), the IP group destination address of the multicast packet MUST be mapped to the multicast SNDU Destination Address (following the method used to generate a destination MAC address in Ethernet). The method for mapping IPv4 multicast addresses is specified in [RFC1112]. The method for mapping IPv6 multicast addresses is specified in [RFC2464].
PDUは、IPマルチキャストパケットであるとSNDU先アドレスが（D = 0）が存在する場合、マルチキャストパケットのIPグループ宛先アドレスは、宛先MACアドレスを生成するために使用される方法に従って（マルチキャストSNDUの宛先アドレスにマッピングする必要がありますイーサネットで）。マッピングIPv4マルチキャストアドレスのための方法は、[RFC1112]で指定されています。マッピングIPv6マルチキャストアドレスのための方法は、[RFC2464]で指定されています。
Each SNDU MUST carry a 32-bit CRC field in the last four bytes of the SNDU. This position eases CRC computation by hardware. The CRC-32 polynomial is to be used. Examples where this polynomial is also employed include Ethernet, DSM-CC section syntax [ISO-DSMCC], and AAL5 [ITU-3563]. This is a 32-bit value calculated according to the generator polynomial represented 0x104C11DB7 in hexadecimal:
各SNDUは、SNDUの最後の4バイトの32ビットCRCフィールドを運ばなければなりません。この位置は、ハードウェアによってCRC計算が容易になります。 CRC-32多項式が使用されます。この多項式も採用されている例は、イーサネット（登録商標）、DSMCCセクション構文[ISO-DSMCC]、及びAAL5 [ITU-3563]を含みます。この16進数で0x104C11DB7表さ生成多項式に従って計算32ビット値です。
x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^7+x^5+x^4+x^2+x^1+x^0.
X ^ 32 + X ^ 26 + X ^ 23 + X ^ 22 + X ^ 16 + X ^ 12 + X ^ 11 + X ^ 10 + X ^ 8 + X ^ 7 + X ^ 5 + X ^ 4 + X ^ 2 + X ^ 1 + X ^ 0。
The Encapsulator initialises the CRC-32 accumulator register to the value 0xFFFF FFFF. It then accumulates a transmit value for the CRC32 that includes all bytes from the start of the SNDU header to the end of the SNDU (excluding the 32-bit trailer holding the CRC-32), and places this in the CRC Field. In ULE, the bytes are processed in order of increasing position within the SNDU; the order of processing bits is NOT reversed. This use resembles, but is different from that in SCTP [RFC3309].
エンカプスレータは、値が0xFFFF FFFFにCRC-32、アキュムレータ・レジスタを初期化します。次に、CRCフィールドのすべて（CRC32を保持する32ビットのトレーラを除く）SNDUの端にSNDUヘッダの先頭からのバイト、及び場所これを含むCRC32ための送信値を蓄積します。 ULEでは、バイトは、SNDU内の位置の昇順で処理されます。処理ビットの順序が反転しません。この使用は似ているが、SCTP [RFC3309]とは異なっています。
The Receiver performs an integrity check by independently calculating the same CRC value and comparing this with the transmitted value in the SNDU trailer. SNDUs that do not have a valid CRC are discarded, causing the Receiver to enter the Idle State.
受信機は、独立して、同じCRC値を計算し、SNDUトレーラに送信された値とこれを比較することにより、整合性チェックを行います。有効なCRCを持っていないSNDUsはアイドル状態に入るためにレシーバーを引き起こし、破棄されます。
This description may be suited for hardware implementation, but this document does not imply any specific implementation. Software-based table-lookup or hardware-assisted software-based implementations are also possible. Appendix B provides an example of an Encapsulated PDU that includes the computed CRC-32 value.
この説明は、ハードウェア実装に適してもよいが、この文書には、任意の特定の実装を意味するものではありません。ソフトウェアベースのテーブルルックアップまたはハードウェア支援ソフトウェアベースの実装も可能です。付録Bは、計算されたCRC-32値を含むカプセル化されたPDUの例を提供します。
The primary purpose of this CRC is to protect the SNDU (header and payload) from undetected reassembly errors and errors introduced by unexpected software/hardware operation while the SNDU is in transit across the MPEG-2 subnetwork and during processing at the Encapsulator and/or the Receiver. It may also detect the presence of uncorrected errors from the physical link (however, these may also be detected by other means, e.g., section 7.3).
SNDUは、MPEG-2のサブネットワークを横切って輸送中及びエンカプスレータの処理中である間、このCRCの主な目的は、予期しないソフトウェア/ハードウェアの動作によって導入未検出再構成エラーとエラーからSNDU（ヘッダ及びペイロード）を保護すること、および/または受信機。また、物理リンクから未補正のエラーの存在を検出することができる（ただし、これらはまた、他の手段によって検出することができる、例えば、セクション7.3）。
The format of an SNDU is determined by the combination of the Destination Address Absent bit (D) and the SNDU Type field. The simplest encapsulation places a PDU directly into an SNDU payload. Some Type 1 encapsulations may require additional header fields. These are inserted in the SNDU following the NPA destination address and directly preceding the PDU.
SNDUのフォーマットは、宛先アドレス不在ビット（D）とSNDUタイプフィールドの組み合わせによって決定されます。最も単純なカプセル化は、SNDUペイロードに直接PDUを置きます。いくつかのタイプ1のカプセル化は、付加的なヘッダフィールドを必要とし得ます。これらは、NPA先アドレス以下と直接PDUの前SNDUに挿入されています。
The following SNDU Formats are defined here:
次SNDUフォーマットは、ここで定義されています。
End Indicator: The Receiver should enter the Idle State (4.7.1). IPv4 SNDU: The payload is a complete IPv4 datagram (4.7.2). IPv6 SNDU: The payload is a complete IPv6 datagram (4.7.3). Test SNDU: The payload will be discarded by the Receiver (5.1). Bridged SNDU: The payload carries a bridged MAC frame (5.2).
終了インジケータ：レシーバがアイドル状態（4.7.1）を入力する必要があります。 IPv4のSNDU：ペイロードが完全なIPv4のデータグラム（4.7.2）です。 IPv6のSNDU：ペイロードが完全なIPv6データグラム（4.7.3）です。試験SNDU：ペイロードはレシーバ（5.1）によって廃棄されるであろう。ブリッジSNDU：ペイロードがブリッジMACフレーム（5.2）を運びます。
Other formats may be defined through relevant assignments in the IEEE and IANA registries.
他の形式は、IEEEとIANAレジストリに関連する割り当てを介して定義することができます。
The format of the End Indicator is shown in figure 2. This format MUST carry a D-bit value of 1.
終了インジケータのフォーマットは、このフォーマットは1のDビット値を搬送しなければならない。図2に示されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| 0x7FFF | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= A sequence of zero or more bytes with a value 0xFF filling =
| the remainder of the TS Packet Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Format for a ULE End Indicator
図2：ULE終了インジケータのためのフォーマット
IPv4 datagrams are directly transported using one of the two standard SNDU structures, in which the PDU is placed directly in the SNDU payload. The two encapsulations are shown in Figures 3 and 4. (Note that in this, and the following figures, the IP datagram payload is of variable size and is directly followed by the CRC-32).
IPv4データグラムを直接PDUをSNDUペイロードに直接配置されているつの標準SNDU構造、のいずれかを使用して搬送されます。 2つのカプセル化は、図3及び図4に示されている（ここでなお、及び以下の図面、IPデータグラムのペイロードが可変サイズであり、直接的に続いているCRC-32）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SNDU Format for an IPv4 Datagram using L2 filtering (D=0)
図3：L2フィルタリングを用いたIPv4データグラムのためのSNDUフォーマット（D = 0）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv4 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SNDU Format for an IPv4 Datagram using L3 filtering (D=1)
図4：L3フィルタリングを用いたIPv4データグラムのためのSNDUフォーマット（D = 1）
IPv6 datagrams are directly transported using one of the two standard SNDU structures, in which the PDU is placed directly in the SNDU payload. The two encapsulations are shown in Figures 5 and 6.
IPv6データグラムを直接PDUをSNDUペイロードに直接配置されているつの標準SNDU構造、のいずれかを使用して搬送されます。 2つのカプセル化は、図5及び図6に示されています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SNDU Format for an IPv6 Datagram using L2 filtering (D=0)
図5：L2フィルタリングを使用したIPv6データグラムのためのSNDUフォーマット（D = 0）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x86DD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= IPv6 datagram =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: SNDU Format for an IPv6 Datagram using L3 filtering (D=1)
図6：L3フィルタリングを使用したIPv6データグラムのためのSNDUフォーマット（D = 1）
This section describes an extension format for the ULE encapsulation. In ULE, a Type field value less than 1536 decimal indicates an Extension Header. These values are assigned from a separate IANA registry defined for ULE.
このセクションでは、ULEカプセル化のための拡張フォーマットを説明しています。 ULE、Typeフィールドの値未満1536小数は拡張ヘッダを示します。これらの値は、ULEために定義された別のIANAレジストリから割り当てられます。
The use of a single Type/Next-Header field simplifies processing and eliminates the need to maintain multiple IANA registries. The cost is that each Extension Header requires at least 2 bytes. This is justified, on the basis of simplified processing and maintaining a simple lightweight header for the common case when no extensions are present.
シングルタイプ/次のヘッダフィールドの使用は、処理を簡素化し、複数のIANAレジストリを維持する必要性を排除します。コストは、各拡張ヘッダは、少なくとも2つのバイトを必要とすることです。これは簡略化の処理に基づいて、正当化およびNO拡張が存在しない場合に一般的なケースのための単純な軽量ヘッダを維持しています。
A ULE Extension Header is identified by a 16-bit value in the Type field. This field is organised as a 5-bit zero prefix, a 3-bit H-LEN field, and an 8-bit H-Type field, as follows:
ULE拡張ヘッダタイプフィールドの16ビット値によって識別されます。次のようにこのフィールドは、5ビットのゼロプレフィックス、3ビットのH-LENフィールドと、8ビットのH-Typeフィールドとして編成されます。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0|H-LEN| H-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Structure of ULE Next-Header Field
図7：ULEネクストヘッダフィールドの構造
The H-LEN Assignment is described below:
H-LENの割り当てについて説明します。
0 Indicates a Mandatory Extension Header 1 Indicates an Optional Extension Header of length 2B (Type only) 2 Indicates an Optional Extension Header of length 4B (Type + 2B) 3 Indicates an Optional Extension Header of length 6B (Type + 4B) 4 Indicates an Optional Extension Header of length 8B (Type + 6B) 5 Indicates an Optional Extension Header of length 10B (Type + 8B)
0必須拡張ヘッダ1は、長さ2B（専用タイプ）2長さ（b）（タイプ+ 2B）のオプション拡張ヘッダを示し3のオプション拡張ヘッダは、長さ6B（タイプ+ 4B）4のオプション拡張ヘッダを示し示し示し示し長さ（b）（タイプ+ 6B）5のオプション拡張ヘッダは、長さ10Bのオプション拡張ヘッダ（タイプ+（b））を示し
>=6 The combined H-LEN and H-TYPE values indicate the EtherType of a PDU that directly follows this Type field.
> = 6合成H-LEN及びH-TYPE値は、直接タイプフィールドの後に続くPDUのイーサタイプを示します。
The H-LEN value indicates the total number of bytes in an Optional Extension Header (including the 2B Type field).
H-LEN値（2Bタイプフィールドを含む）オプション拡張ヘッダ内のバイトの総数を示します。
An H-LEN value of zero indicates a Mandatory Extension Header. Each Mandatory Extension Header has a pre-defined length that is not communicated in the H-LEN field. No additional limit is placed on the maximum length of a Mandatory Extension Header. A Mandatory Extension Header MAY modify the format or encoding of the enclosed PDU (e.g., to perform encryption and/or compression).
ゼロのH-LEN値が必須の拡張ヘッダを示します。各必須の拡張ヘッダは、H-LENフィールドで伝達されていない予め定義された長さを有します。追加の制限は必須拡張ヘッダの最大長さに配置されていません。必須の拡張ヘッダが封入PDUのフォーマットまたは符号化を変更することができる（例えば、暗号化および/または圧縮を実行します）。
The H-Type is a one-byte field that is either one of 256 Mandatory Header Extensions or one of 256 Optional Header Extensions. The set of currently permitted values for both types of Extension Headers are defined by an IANA Registry (section 15). Registry values for Optional Extensions are specified in the form H=1 (i.e., a decimal number in the range 256-511), but may be used with an H-Length value in the range 1-5 (see example in section 5.3).
H-Typeが256の必須ヘッダ拡張の1または256のオプションヘッダー拡張の1のいずれかである1バイトのフィールドです。拡張ヘッダの両方のタイプの現在許可される値のセットは、IANAレジストリ（セクション15）によって定義されます。オプションの拡張のためのレジストリ値は、フォームH = 1（すなわち、範囲256から511までの10進数）で指定されているが、範囲1-5 H-Length値で使用することができる（セクション5.3の例を参照） 。
Two examples of Extension Headers are the Test SNDU and the use of Extension-Padding. The Test SNDU Mandatory Extension Header results in the entire PDU's being discarded. The Extension-Padding Optional Extension Header results in the following (if any) option header being ignored (i.e., a total of H-LEN 16-bit words).
拡張ヘッダーの2つの例は、テストSNDUと拡張パディングの使用です。全体のPDUの中のテストSNDU必須の拡張ヘッダの結果は破棄されます。オプションヘッダは無視される（もしあれば）は、以下の（即ち、H-LEN、16ビット・ワードの合計）における拡張パディングオプションの拡張ヘッダをもたらします。
The general format for an SNDU with Extension Headers is:
拡張ヘッダーとSNDUのための一般的な形式は次のとおりです。
< -------------------------- SNDU ------------------------- >
+---+--------------------------------------------------+--------+
|D=0| Length | T1 | NPA Address | H1 | T2 | PDU | CRC-32 |
+---+--------------------------------------------------+--------+
< ULE base header > < ext 1 >
Figure 8: SNDU Encapsulation with one Extension Header (for D=0)
図8（D = 0）を一度拡張ヘッダでカプセル化SNDU
Where: D is the ULE D_bit (in this example D=0; however, NPA addresses may also be omitted when using Extension Headers). T1 is the base header Type field. In this case, specifying a Next-Header value. H1 is a set of fields defined for header type T1. There may be 0 or more bytes of information for a specific ULE Extension Header. T2 is the Type field of the next header, or an EtherType > 1535 B indicating the type of the PDU being carried.
ここで、Dは、ULE D_bit（;拡張ヘッダを使用する場合しかし、NPAアドレスは省略することも可能で、この例ではD = 0）です。 T1は、基本ヘッダのTypeフィールドです。この場合、次のページヘッダの値を指定します。 H1は、ヘッダタイプT1に対して定義されたフィールドのセットです。特定ULE拡張ヘッダ情報の0バイト以上があるかもしれません。 T2は次のヘッダのTypeフィールド、または運ばれるPDUの種類を示すのEtherType> 1535 Bです。
< -------------------------- SNDU ------------------------- >
+---+---------------------------------------------------+--------+
|D=1| Length | T1 | H1 | T2 | H2 | T3 | PDU | CRC-32 |
+---+---------------------------------------------------+--------+
< ULE base header >< ext 1 >< ext 2 >
Figure 9: SNDU Encapsulation with two Extension Headers (D=1)
図9は2つの拡張ヘッダとSNDUカプセル化（D = 1）
Using this method, several Extension Headers MAY be chained in series. Figure 12 shows an SNDU including two Extension Headers. In the example, the values of T1 and T2 are both less than 1536 decimal. Each indicates the presence of an Extension Header, rather than a directly following PDU. T3 has a value > 1535 indicating the EtherType of the PDU being carried. Although an SNDU may contain an arbitrary number of consecutive Extension Headers, it is not expected that SNDUs will generally carry a large number of extensions.
この方法を使用して、いくつかの拡張ヘッダーを直列に連鎖されるかもしれません。図12は、2つの拡張ヘッダを含むSNDUを示しています。一例では、T1とT2の値が1536未満小数の両方です。それぞれがなく、直接次のPDUよりも、拡張ヘッダの存在を示します。 T3は、PDUのイーサタイプを示す値> 1535が実施されています。 SNDUが連続拡張ヘッダーの任意の数を含むことができますが、SNDUsは、一般的に拡張子を大量に運ぶことが期待されていません。
A Test SNDU (Figure 10) is a Mandatory Extension Header of Type 1. This header must be the final (or only) extension header specified in the header chain of an SNDU. The structure of the Data portion of this SNDU is not defined by this document. Receivers MAY record reception in a log file, but MUST then discard any Test SNDUs. The D-bit MAY be set in a TEST SNDU.
テストSNDU（図10）は、このヘッダは、SNDUのヘッダ鎖で指定最終（または唯一の）拡張ヘッダでなければならないタイプ1の必須拡張ヘッダです。このSNDUのデータ部分の構造は、この文書で定義されていません。レシーバは、ログファイルの受信を記録することができるが、その後、任意のテストSNDUsを捨てなければなりません。 Dビットは、試験SNDUに設定されてもよいです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D| Length (15b) | Type = 0x0000 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= Data (not forwarded by a Receiver) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: SNDU Format for a Test SNDU
図10：テストSNDUためSNDUフォーマット
A bridged SNDU is a Mandatory Extension Header of Type 1. It MUST be the final (or only) extension header specified in the header chain of an SNDU. The payload includes MAC address and EtherType [DIX] or LLC Length [ISO-8802-2] fields together with the contents of a bridged MAC frame. The SNDU has the format shown in Figures 11 and 12.
架橋SNDUは、SNDUのヘッダ鎖で指定最終（または唯一の）拡張ヘッダでなければなりませんタイプ1必須の拡張ヘッダです。ペイロードは、一緒にブリッジMACフレームの内容とMACアドレスとEtherType [DIX]またはLLC長[ISO-8802-2]フィールドを含みます。 SNDUは、図11及び図12に示すフォーマットを有しています。
When an NPA address is specified (D=0), Receivers MUST discard all SNDUs that carry an NPA destination address that does NOT match their own NPA address (or a broadcast/multicast address); the payload of the remaining SNDUs are processed by the bridging rules that follow. An SNDU without an NPA address (D=1) results in a Receiver performing bridging processing on the payload of all received SNDUs.
NPAアドレスが指定されている場合（D = 0）、受信機は、独自のNPAアドレス（またはブロードキャスト/マルチキャストアドレス）と一致しないNPA宛先アドレスを運ぶ全てSNDUsを捨てなければなりません。残りSNDUsのペイロードは、以下ブリッジングルールによって処理されます。 NPAアドレス（D = 1）ことなくSNDUレシーバの結果は、すべてのペイロードに架橋処理を行うことがSNDUsを受けました。
An Encapsulator MAY also use this encapsulation format to directly communicate network protocol packets that require the LLC encapsulation [IEEE-802.2, ISO-8802-2]. To do this, it constructs an SNDU with a Bridge Extension Header containing the intended destination MAC address, the MAC source address of the Encapsulator, and the LLC-Length. The PDU comprises an LLC header followed by the required payload. The Encapsulator MAY choose to suppress the NPA address (see 4.5).
エンカプスレータは直接LLCカプセル化[IEEE-802.2、ISO-8802-2]を必要とするネットワーク・プロトコル・パケットを通信するために、このカプセル化フォーマットを使用してもよいです。これを行うには、それが意図した宛先MACアドレス、カプセル化機能のMAC送信元アドレス、およびLLC-長を含むブリッジ拡張ヘッダーとSNDUを構築します。 PDUは、必要なペイロードが続くLLCヘッダを含みます。エンキャプはNPAアドレス（4.5を参照）を抑制することを選択するかもしれません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Length (15b) | Type = 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Destination NPA Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Destination Address (6B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Source Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | EtherType/LLC-Length (2B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
= (Contents of bridged MAC frame) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: SNDU Format for a Bridged Payload (D=0)
図11：ブリッジペイロードのSNDUフォーマット（D = 0）
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1| Length (15b) | Type = 0x0001 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Destination Address (6B) |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Source Address (6B) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EtherType/LLC-Length (2B) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
= (Contents of bridged MAC frame) =
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (CRC-32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: SNDU Format for a Bridged Payload (D=1)
図12：ブリッジペイロードのSNDUフォーマット（D = 1）
The EtherType/LLC-Length field of a frame is defined according to IEEE 802.3 [IEEE-802.2] (see section 5).
フレームのイーサタイプ/ LLC-Lengthフィールドは、IEEE 802.3 [IEEE-802.2]に従って定義される（セクション5を参照）。
In this special case, the Mandatory Extension Header format may be interpreted as either an EtherType [DIX] or an LLC Length field, specified by IEEE 802 [IEEE-802.3] rather than as a value assigned in the ULE Next-Header Registry maintained by the IANA.
この特別な場合には、必須の拡張ヘッダのフォーマットは、イーサタイプ[DIX]またはIEEE 802で指定されたLLC長フィールド、[IEEE-802.3]のいずれかとしてではなくによって維持ULE次にヘッダレジストリに割り当てられた値として解釈することができますIANA。
The MAC addresses in the frame being bridged SHOULD be assigned according to the rules specified by the IEEE and denote unknown, unicast, broadcast, and multicast link addresses. These MAC addresses denote the intended recipient in the destination LAN, and therefore have a different function from the NPA addresses carried in the SNDU header.
架橋されたフレーム内のMACアドレスは、IEEEによって指定および未知のユニキャスト、ブロードキャスト、およびマルチキャストリンクアドレスを示す規則に従って割り当てられるべきです。これらのMACアドレスは、宛先LANに意図された受信者を示し、したがってSNDUヘッダで運ばNPAアドレスとは異なる機能を有しています。
A frame Type < 1536 for a bridged frame introduces a LLC Length field. The Receiver MUST check this length and discard any frame with a length greater than permitted by the SNDU payload size.
ブリッジフレームのフレームタイプ<1536は、LLCの長さフィールドを紹介します。受信機は、この長さをチェックし、SNDUペイロードサイズによって許容さよりも大きい長さを有する任意のフレームを破棄しなければなりません。
In normal operation, it is expected that any padding appended to the Ethernet frame SHOULD be removed prior to forwarding. This requires the sender to be aware of such Ethernet padding (e.g., [DIX, IEEE-802.3]).
通常の動作では、イーサネットフレームに付加され、任意のパディングを転送する前に除去されるべきであることが予想されます。これは、イーサネットパディングを認識するために、送信者を必要とする（例えば、[DIX、IEEE-802.3]）。
Ethernet frames received at the Encapsulator for onward transmission over ULE carry a Local Area Network Frame Check sequence (LAN FCS) field (e.g., CRC-32 for Ethernet [DIX, IEEE-802.3]). The Encapsulator MUST check the LAN-FCS value of all frames received, prior to further processing. Frames received with an invalid LAN FCS MUST be discarded. After checking, the LAN FCS is then removed (i.e., it is NOT forwarded in the bridged SNDU). As in other ULE frames, the Encapsulator appends a CRC-32 to the transmitted SNDU. At the Receiver, an appropriate LAN-FCS field will be appended to the bridged frame prior to onward transmission on the Ethernet interface.
イーサネットフレームは、以降の送信上ULEローカルエリアネットワークフレームチェックシーケンスを運ぶ（LAN FCS）フィールドのエンカプスレータで受信（例えば、イーサネット（登録商標）のためのCRC-32 [DIX、IEEE-802.3]）。エンカプスレータは、さらなる処理の前に、受信されたすべてのフレームのLAN-FCS値をチェックしなければなりません。無効なLAN FCSで受信したフレームを捨てなければなりません。確認した後、LAN FCSは次に（すなわち、それは架橋SNDUで転送されていない）が除去されます。他のULEのフレームのように、カプセル化機能は、送信されたSNDUにCRC-32を付加します。受信機において、適切なLAN-FCSフィールドは、前のイーサネットインターフェイス上の以降の送信にブリッジフレームに付加されます。
This design is readily implemented using existing network interface cards and does not introduce an efficiency cost by calculating/verifying two integrity check fields for bridged frames. However, it also introduces the possibility that a frame corrupted within the processing performed at an Encapsulator and/or Receiver may not be detected by the final recipient(s) (i.e., such corruption would not normally result in an invalid LAN FCS).
この設計は、容易に既存のネットワークインターフェイスカードを使用して実装されており、ブリッジ・フレーム用の2つの整合性チェックのフィールドを検証する/計算することにより、効率のコストを導入しません。しかし、それはまた、カプセル化機能および/または受信機において実行される処理内で破損したフレーム（すなわち、そのような破損は、通常、無効LAN FCSをもたらさないであろう）最終受信者（単数または複数）によって検出されない可能性を導入します。
The Extension-Padding Optional Extension Header is specified by an IANA-assigned H-Type value of 0x100. As in other Optional Extensions, the total length of the extension is indicated by the H-LEN field (specified in 16-bit words). The extension field is formed of a group of one to five 16-bit fields.
拡張パディングオプション拡張ヘッダは、0x100ののIANAによって割り当てられたH型の値で指定されます。他の任意の拡張と同様に、拡張の全長は（16ビット・ワードで指定された）H-LENフィールドによって示されています。拡張フィールドは、1〜5個の16ビット・フィールドのグループによって形成されています。
For this specific option, only the last 16-bit word has an assigned value; the sender SHOULD set the remaining values to 0x0000. The last 16-bit field forms the Next-Header Type field. A Receiver MUST interpret the Type field, but MUST ignore any other fields of this Extension Header.
この特定のオプションでは、最後の16ビットワードが割り当てられた値を有します。送信者は0x0000に残りの値を設定する必要があります。最後の16ビットのフィールドは、次の-ヘッダタイプフィールドを形成しています。レシーバは、Typeフィールドを解釈しなければならないが、この拡張ヘッダの他のフィールドを無視しなければなりません。
The Encapsulator forms the PDUs queued for transmission into SNDUs by adding a header and trailer to each PDU (section 4). It then segments the SNDU into a series of TS Packet payloads (Figure 13). These are transmitted using a single TS Logical Channel over a TS Multiplex. The TS Multiplex may be processed by a number of MPEG-2 (re)multiplexors before it is finally delivered to a Receiver [RFC4259].
エンカプスレータは、PDUは各PDU（セクション4）のヘッダとトレーラを追加することによってSNDUsへの送信のためにキューに入れられた構成します。 TSパケットペイロード（図13）のシリーズにそれからセグメントSNDUを。これらは、TS多重上の単一TS論理チャネルを使用して送信されます。それが最終的に受信[RFC4259]に配信される前に、TS多重化は、MPEG-2（再）マルチプレクサの数で処理することができます。
+------+--------------------------------+------+
| ULE | Protocol Data Unit | ULE |
|Header| |CRC-32|
+------+--------------------------------+------+
/ / \ \
/ / \ \
/ / \ \
+--------+---------+ +--------+---------+ +--------+---------+
|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |...|MPEG-2TS| MPEG-2 |
| Header | Payload | | Header | Payload | | Header | Payload |
+--------+---------+ +--------+---------+ +--------+---------+
Figure 13: Encapsulation of an SNDU into a series of TS Packets
図13：TSパケットの系列にSNDUのカプセル化
When an Encapsulator has not previously sent a TS Packet for a specific TS Logical Channel, or after an Idle period, it starts to send an SNDU in the first available TS Packet. This first TS Packet generated MUST carry a PUSI value of 1. It MUST also carry a Payload Pointer value of zero, indicating that the SNDU starts immediately after the Payload Pointer in the TS Packet payload.
キャプは以前に論理チャネルの特定のTSのためのTSパケットを送信していない場合、またはアイドル期間の後に、それは最初に使用可能なTSパケットにSNDUを送信するために開始します。この最初のTSパケットは、SNDUは、TSパケットペイロード内のペイロード・ポインタの直後に開始することを示し、また、ゼロのペイロードポインタ値を運ばなければなりません1のPUSI値を運ばなければなりません生成しました。
The Encapsulation MUST ensure that all TS Packets set the MPEG-2 Continuity Counter carried in the TS Packet header, according to [ISO-MPEG2]. This value MUST be incremented by one (modulo 16) for each successive TS Packet containing a fragment/complete SNDU sent using the same TS Logical Channel.
カプセル化は、すべてのパケットは[ISO-MPEG2]によれば、TSパケットヘッダで運ばMPEG2継続カウンタを設定するTSことを確認しなければなりません。この値は、同じTS論理チャネルを用いて送信断片/完全SNDUを含む連続する各TSパケットに対して1つ（モジュロ16）だけインクリメントされなければなりません。
An Encapsulator MAY decide not to send another SNDU immediately, even if space is available in a partially filled TS Packet. This procedure is known as Padding (Figure 14). The End Indicator informs the Receiver that there are no more SNDUs in this TS Packet payload. The End Indicator is followed by zero or more unused bytes until the end of the TS Packet payload. All unused bytes MUST be set to the value of 0xFF, following current practice in MPEG-2 [ISO-DSMCC]. The Padding procedure trades decreased efficiency against improved latency.
カプセル化機能は、スペースが部分的に満たされたTSパケットで利用可能な場合であっても、すぐに別のSNDUを送信しないことを決定してもよいです。この手順は、パディング（図14）として知られています。終了インジケータは、これは、パケットのペイロードをTSにこれ以上のSNDUsがあることを受信者に通知します。終了インジケータは、TSパケットペイロードの最後までゼロ個以上の未使用バイトが続きます。すべての未使用のバイトは、MPEG-2 [ISO-DSMCC]における現在の慣行に従って、値0xFFに設定しなければなりません。パディング手順取引は、改良された待ち時間に対して効率を減少させました。
+-/------------+
| SubNetwork |
| DU 1 |
+-/------------+
\ \
\ \
\ \
+--------+--------+--------+----------+
|MPEG-2TS| End of | 0xFFFF | Unused |
| Header | SNDU 1 | | Bytes |
+--------+--------+--------+----------+
PUSI=0 ULE
End
Indicator
Figure 14: A TS Packet carrying the end of SNDU 1, followed by an End Indicator
図14：エンドインジケータ続いSNDU 1の端部を担持するTSパケット、
Alternatively, when more packets are waiting at an Encapsulator, and a TS Packet has sufficient space remaining in the payload, the Encapsulator can follow a previously encapsulated SNDU with another SNDU using the next available byte of the TS Packet payload (see 6.2). This is called Packing (Figure 15).
あるいは、より多くのパケットがカプセル化機能で待機しており、TSパケットは十分なスペースがペイロード内に残っている、エンカプスレータは、TSパケットペイロードの次の利用可能なバイトを（6.2を参照）を使用して別のSNDUと以前にカプセル化されたSNDUに従うことができます。これは、（図15）パッキングと呼ばれています。
+-/----------------+ +----------------/-+
| Subnetwork | | Subnetwork |
| DU 2 | | DU 3 |
+-/----------------+ +----------------/-+
\ \ / /\
\ \ / / \
\ \ / / \. . .
+--------+--------+--------+----------+
|MPEG-2TS| Payload| end of | start of |
| Header | Pointer| SNDU 2 | SNDU 3 |
+--------+--------+--------+----------+
PUSI=1 | ^
| |
+--------------+
Figure 15: A TS Packet with the end of SNDU 2, followed by SNDU 3
図15：SNDU 2の端部とTSパケット、SNDU 3に続きます
Five possible actions may occur when an Encapsulator has completed encapsulation of an SNDU:
キャプがSNDUのカプセル化を完了したときに可能な5つのアクションが発生する可能性があります。
(i) If the TS Packet has no remaining space, the Encapsulator transmits this TS Packet. It starts transmission of the next SNDU in a new TS Packet. (The standard rules [ISO-MPEG2] require that the header of this new TS Packet carry a PUSI value of 1 followed by a Payload Pointer value of 0x00.)
TSパケットがない残りの空間を有していない場合は（I）、エンカプスレータは、このTSパケットを送信します。これは、新しいTSパケット内の次のSNDUの送信を開始します。 （標準ルール[ISO-MPEG2は、この新たなTSパケットのヘッダが0x00でのペイロードポインタ値に続く1のPUSI値を伝送することを必要とします。）
(ii) If the TS Packet carrying the final part of an SNDU has one byte of unused payload, the Encapsulator MUST place the value 0xFF in this final byte and transmit the TS Packet. This rule provides a simple mechanism to resolve the complex behaviour that may arise when the TS Packet has no PUSI set. To send another SNDU in the current TS Packet would otherwise require the addition of a Payload Pointer that would consume the last remaining byte of TS Packet payload. The behaviour follows similar practice for other MPEG-2 payload types [ISO-DSMCC]. The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 followed by a Payload Pointer value of 0x00.)
SNDUの最後の部分を運ぶTSパケットが未使用のペイロードの1つのバイトがある場合（ii）は、エンカプスレータは、この最後のバイトの値は0xFFを配置し、TSパケットを送信しなければなりません。この規則は、TSパケットが全くPUSIが設定されていない場合に発生する可能性のある複雑な問題を解決するための簡単なメカニズムを提供します。そうでない場合は、TSパケットのペイロードの最後の残りのバイトを消費するペイロードポインタの追加を必要とする現在のTSパケット内の別のSNDUを送信します。動作は、他のMPEG-2ペイロードタイプ[ISO-DSMCC]のための同様の慣行に従います。カプセル化機能は、新たなTSパケット内の次のSNDUの送信を開始する必要があります。 （標準ルールは0x00でのペイロードポインタ値に続く1のPUSI値を運ぶためにこの新しいTSパケットのヘッダを必要とします。）
(iii) If the TS Packet carrying the final part of an SNDU has exactly two bytes of unused payload, and the PUSI was NOT already set, the Encapsulator MUST place the value 0xFFFF in these final two bytes, providing an End Indicator (section 4.3), and transmit the TS Packet. This rule prevents fragmentation of the SNDU Length field over two TS Packets. The Encapsulator MUST start transmission of the next SNDU in a new TS Packet. (The standard rules require the header of this new TS Packet to carry a PUSI value of 1 followed by a Payload Pointer value of 0x00.)
SNDUの最後の部分を運ぶTSパケットは、未使用のペイロードの正確2つのバイトを有し、PUSIが既に設定されていなかった場合（III）、エンカプスレータは、エンド・インジケータ（セクション4.3を提供し、これらの最終の2バイトの値が0xFFFFを配置しなければなりません）、およびTSパケットを送信します。このルールは2つのTSパケット上SNDUの長さフィールドの断片化を防ぐことができます。カプセル化機能は、新たなTSパケット内の次のSNDUの送信を開始する必要があります。 （標準ルールは0x00でのペイロードポインタ値に続く1のPUSI値を運ぶためにこの新しいTSパケットのヘッダを必要とします。）
(iv) If the TS Packet has more than two bytes of unused payload, the Encapsulator MAY transmit this partially full TS Packet but MUST first place the value 0xFF in all remaining unused bytes (i.e., setting an End Indicator followed by Padding). The Encapsulator MUST then start transmission of the next SNDU in a new TS Packet. (The standard rules [ISO-MPEG2] require that the header of this new TS Packet carry a PUSI value of 1 and a Payload Pointer value of 0x00.)
TSパケットは、未使用のペイロードつ以上のバイトがある場合（IV）、エンカプスレータは、この部分的に完全なTSパケットを送信することができるが、最初にすべての残りの未使用のバイトの値は0xFFを配置しなければならない（即ち、パディング続い終了インジケータを設定します）。カプセル化機能は、新しいTSパケット内の次のSNDUの送信を開始する必要があります。 （標準ルール[ISO-MPEG2は、この新たなTSパケットのヘッダは、1のPUSI値とは0x00のペイロードポインタ値を運ぶことを必要とします。）
(v) If at least two bytes are available for SNDU data in the TS Packet payload (i.e., three bytes if the PUSI was NOT previously set, and two bytes if it was previously set), the Encapsulator MAY encapsulate further queued PDUs, by starting the next SNDU in the next available byte of the current TS Packet payload. When the Encapsulator packs further SNDUs into a TS Packet where the PUSI has
（v）は、少なくとも2つのバイトがTSパケットのペイロードにおけるSNDUデータの利用可能な場合（つまり、PUSIが予め設定されていない場合は3バイト、そしてそれは以前に設定された場合は2バイト）は、さらにカプセル化することができるカプセル化機能はによって、PDUをキューに入れられました現在のTSパケットのペイロードの次に使用可能なバイトに次のSNDUを開始します。カプセル化機能は、PUSIが持つTSパケットにさらにSNDUsをパックするとき
NOT already been set, the PUSI MUST be updated (set to 1), and an 8-bit Payload Pointer MUST be inserted in the first byte directly following the TS Packet header. (This reduces the size of the TS Packet payload field that is available for data by one byte.) The value of the Payload Pointer MUST be set to the position of the byte following the end of the first SNDU in the TS Packet payload. If no further PDUs are available, an Encapsulator MAY wait for additional PDUs to fill the incomplete TS Packet. The maximum period of time an Encapsulator can wait, known as the Packing Threshold, MUST be bounded and SHOULD be configurable in the Encapsulator. If sufficient additional PDUs are NOT received to complete the TS Packet within the Packing Threshold, the Encapsulator MUST insert an End Indicator (using rule iv).
既に設定されていない、PUSIが（1に設定）が更新されなければならない、8ビットペイロードポインタは、TSパケットヘッダに続く直接最初のバイトに挿入されなければなりません。 （これは、1バイトのデータのために利用可能であるTSパケットのペイロードフィールドのサイズを減少させる。）ペイロードポインタの値をTSパケットペイロードの最初SNDUの端以下のバイトの位置に設定しなければなりません。それ以上のPDUが利用できない場合は、エンキャプは不完全TSパケットを埋めるために、追加のPDUを待つことができます。パッキングしきい値として知られているカプセル化機能が待つことのできる時間の最大期間は、有界なければなりません、そして、カプセル化機能で設定可能であるべきです。十分な追加のPDUは、パッキングしきい値内TSパケットを完了するために、受信されない場合は、エンキャプは終了インジケータ（使用してルールIV）を挿入する必要があります。
Use of the Packing method (v) by an Encapsulator is optional and may be determined on a per-session, per-packet, or per-SNDU basis.
エンカプスレータにより梱包方法（V）の使用はオプションで、セッションごと、パケットごと、または毎SNDUに基づいて決定されてもよいです。
When an SNDU is less than the size of a TS Packet payload, a TS Packet may be formed that carries a PUSI value of one and also an End Indicator (using rule iv).
SNDUは、TSパケットペイロードのサイズより小さい場合、TSパケットは、一つのPUSI値と（ルールIVを使用して）、エンドインジケータを搬送するように形成されてもよいです。
A Receiver tunes to a specific TS Multiplex carrying a ULE Stream and sets a receive filter to accept all TS Packets with a specific PID. These TS Packets are associated with a specific TS Logical Channel and are reassembled to form a stream of SNDUs. A single Receiver may be able to receive multiple TS Logical Channels, possibly using a range of TS Multiplexes. In each case, reassembly MUST be performed independently for each TS Logical Channel. To perform this reassembly, the Receiver may use a buffer to hold the partially assembled SNDU, referred to here as the Current SNDU buffer. Other implementations may choose to use other data structures, but MUST provide equivalent operations.
ULEストリームを運ぶ特定のTS多重化するためにレシーバの曲や、特定のPIDを持つすべてのTSパケットを受け入れるように受信フィルタを設定します。これらのTSパケットは、特定のTS論理チャネルに関連付けられており、SNDUsの流れを形成するように再構築されます。単一の受信機は、おそらくTSマルチプレックスの範囲を使用して、複数のTS論理チャネルを受信することであってもよいです。それぞれのケースで、再組み立ては、各論理チャネルのTSのために独立して実行しなければなりません。この再アセンブリを実行するために、受信機は、現在SNDUバッファとしてここで呼ばれる部分的に組み立てられたSNDUを保持するためにバッファを使用することができます。他の実装は、他のデータ構造を使用することを選択するかもしれませんが、同等の操作を提供しなければなりません。
Receipt of a TS Packet with a PUSI value of 1 indicates that the TS Packet contains the start of a new SNDU. It also indicates the presence of the Payload Pointer (indicating the number of bytes to the start of the first SNDU in the TS-Packet currently being reassembled). It is illegal to receive a Payload Pointer value greater than 181, and this MUST cause the SNDU reassembly to be aborted and the Receiver to enter the Idle State. This event SHOULD be recorded as a payload pointer error.
1のPUSI値を持つTSパケットの受信は、TSパケットが新しいSNDUの開始が含まれていることを示しています。それはまた、ペイロードポインタ（現在再組み立てされるTS-パケット内の最初のSNDUの開始までのバイト数を示す）の存在を示します。 181よりも大きなペイロードポインタ値を受信することは違法であり、これはSNDUの再構築が中止させなければならなくて、受信機がアイドル状態を入力します。このイベントは、ペイロードポインタエラーとして記録されるべきです。
A Receiver MUST support the use of both the Packing and Padding method for any received SNDU and MUST support reception of SNDUs with or without a Destination Address Field (i.e., D=0 and D=1).
受信機は、任意の包装及びパディング方法はSNDUを受信し、宛先アドレスフィールド（すなわち、D = 0、D = 1）の有無にかかわらずSNDUsの受信をサポートしなければならないの両方の使用をサポートしなければなりません。
After initialisation or errors, or on receipt of an End Indicator, the Receiver enters the Idle State. In this state, the Receiver discards all TS Packets until it discovers the start of a new SNDU, upon which it then enters the Reassembly State. Figure 16 outlines these state transitions:
初期化やエラーの後、または終了インジケータを受信すると、レシーバはアイドル状態に入ります。それは、その後の再組み立て状態に入り、その上に新しいSNDUの開始を発見するまで、この状態では、受信機は、すべてのTSパケットを破棄します。図16は、これらの状態遷移の概要を示します。
+-------+
| START |
+---+---+
|
\/
+----------+
\| Idle |/
+-------/| State |\-------+
Insufficient | +----+-----+ |
unused space | | PUSI set | MPEG-2 TS Error
or | \/ | or
End Indicator| +----------+ | SNDU Error
| |Reassembly| |
+--------| State |--------+
+----------+
Figure 16: Receiver state transitions
図16：レシーバの状態遷移
A Receiver in the Idle State MUST check the PUSI value in the header of all received TS Packets. A PUSI value of 1 indicates the presence of a Payload Pointer. Following a loss of synchronisation, values between 0 and 181 are permitted, in which case the Receiver MUST discard the number of bytes indicated by the Payload Pointer (counted from the first byte of the TS Packet payload field, and excluding the PP field itself), before leaving the Idle State. It then enters the Reassembly State, and starts reassembly of a new SNDU at this point.
全てのヘッダ内のPUSI値をチェックしなければならないアイドル状態にある受信機は、TSパケットを受信しました。 1のPUSI値は、ペイロードポインタの存在を示します。同期の損失以下、0と181の間の値を許可され、受信機は、ペイロードポインタ（TSパケットペイロードフィールドの最初のバイトから数え、及びPPフィールド自体を除く）で示されるバイト数を捨てなければならない場合には、アイドル状態を離れる前に。その後、再組み立て状態になり、この時点で新しいSNDUの再構築を開始します。
When in the Reassembly State, the Receiver reads a 2-byte SNDU Length field from the TS Packet payload. If the value is less than or equal to 4, or equal to 0xFFFF, the Receiver discards the Current SNDU and the remaining TS Packet payload and returns to the Idle State. Receipt of an invalid Length field is an error event and SHOULD be recorded as an SNDU length error.
再組み立て状態では、受信機は、TSパケットのペイロードから2バイトSNDUの長さフィールドを読み取ると。値が、0xFFFF未満または4に等しい、または等しい場合、受信機は、現在SNDUと残りのTSパケットペイロードを廃棄し、アイドル状態に戻ります。無効な長さのフィールドの受信は、エラーイベントであるとSNDU長エラーとして記録されるべきです。
If the Length of the Current SNDU is greater than 4, the Receiver accepts bytes from the TS Packet payload to the Current SNDU buffer until either Length bytes in total are received, or the end of the TS Packet is reached (see also 7.2.1). When the Current SNDU length equals the value of the Length field, the Receiver MUST calculate and verify the CRC value (see 4.6). SNDUs that contain an invalid CRC value MUST be discarded. Mismatch of the CRC is an error event and SHOULD be recorded as a CRC error. The underlying physical-layer processing (e.g., forward error correction coding) often results in patterns of errors, rather than single bit errors, so the Receiver needs to be robust to arbitrary patterns of corruption to the TS Packet and payload, including potential corruption of the PUSI, PP, and SNDU Length fields. Therefore, a Receiver SHOULD discard the remaining TS Packet payload (if any) following a CRC mismatch and return to the Idle State.
現在SNDUの長さが4より大きい場合、合計のいずれかの長さのバイトが受信された、またはTSパケットの終わりに達するまで、受信機は、現在SNDUバッファにTSパケットペイロードのバイトを受け付ける（また、7.2.1参照）。現在SNDUの長さは長さフィールドの値に等しい場合、受信機は、（4.6を参照）CRC値を計算して確認しなければなりません。無効なCRC値を含むSNDUsを捨てなければなりません。 CRCの不一致がエラーイベントであるとCRCエラーとして記録されるべきです。基礎となる物理層処理（符号化、例えば、順方向誤り訂正）は、多くの場合、エラーのパターンではなく、シングルビットエラーを生じるので、受信機は、潜在的な破損を含め、任意のTSパケットに腐敗のパターンとペイロードに対してロバストである必要がありますPUSI、PP、及びSNDU長フィールド。したがって、受信機は、CRCの不一致以下の（もしあれば）残りのTSパケットペイロードを破棄し、アイドル状態に戻るべきです。
When the Destination Address is present (D=0), the Receiver accepts SNDUs that match one of a set of addresses specified by the Receiver (this includes the NPA address of the Receiver, the NPA broadcast address, and any required multicast NPA addresses). The Receiver MUST silently discard an SNDU with an unmatched address.
宛先アドレスが存在する場合（D = 0）、受信機は、受信機（これは受信機、NPAブロードキャストアドレスのNPAアドレスを含む、任意のマルチキャストNPAアドレスが必要）で指定されたアドレスのセットのうちの1つに一致SNDUsを受け付け。レシーバは黙って比類のないアドレスでSNDUを捨てなければなりません。
After receiving a valid SNDU, the Receiver MUST check the Type field (and process any Type 1 Extension Headers). The SNDU payload is then passed to the next protocol layer specified. An SNDU with an unknown Type value < 1536 MUST be discarded. This error event SHOULD be recorded as an SNDU type error.
有効SNDUを受信した後、受信機は、タイプフィールドを確認（および任意のタイプの1拡張ヘッダーを処理する）しなければなりません。 SNDUペイロードは、次に、指定された次のプロトコル層に渡されます。未知の種類の値を持つSNDU <1536を捨てなければなりません。このエラーイベントは、SNDUタイプエラーとして記録されるべきです。
The Receiver then starts reassembly of the next SNDU. This MAY directly follow the previously reassembled SNDU within the TS Packet payload.
受信機は、次のSNDUの再構築を開始します。これは、直接TSパケットペイロード内以前に再組み立てSNDUに従うことができます。
(i) If the Current SNDU finishes at the end of a TS Packet payload, the Receiver MUST enter the Idle State.
現在のSNDUをTSパケットペイロードの最後に終了した場合（I）、レシーバはアイドル状態を入力する必要があります。
(ii) If only one byte remains unprocessed in the TS Packet payload after completion of the Current SNDU, the Receiver MUST discard this final byte of TS Packet payload. It then enters the Idle State. It MUST NOT record an error when the value of the remaining byte is identical to 0xFF.
（ii）は1バイトのみが現在SNDUの完了後TSパケットペイロード内の未処理のままである場合、受信機は、TSパケットペイロードのこの最終バイトを破棄しなければなりません。その後、アイドル状態に入ります。残りのバイトの値が0xFFと同じである場合にエラーを記録してはなりません。
(iii) If two or more bytes of TS Packet payload data remain after completion of the Current SNDU, the Receiver accepts the next 2 bytes and examines whether this is an End Indicator. When an End Indicator is received, a Receiver MUST silently discard the remainder of the TS Packet payload and transition to the Idle State. Otherwise, this is the start of the next Packed SNDU, and the Receiver continues by processing this SNDU. (This is provided that the TS Packet has a
TSパケットペイロードデータの2つの以上のバイトが現在SNDUの完了後に残っている場合（iii）は、受信機は、次の2つのバイトを受け入れ、これが終了インジケータであるか否かを調べます。終了インジケータを受信した場合、受信機は静かTSパケットペイロードとアイドル状態への遷移の残りを捨てなければなりません。そうでなければ、これは次のパックされたSNDUの開始であり、受信機は、このSNDUを処理することによって継続します。 （これは、TSパケットを持っていることを提供します
PUSI value of 1, see 7.2.1; otherwise, the Receiver has detected a delimiting error and MUST discard all remaining bytes in the TS Packet payload and transitions to the Idle State.)
1のPUSI値は、7.2.1を参照してください。そうでない場合、受信機は、区切り誤りを検出し、アイドル状態にTSパケットペイロードと遷移における全ての残りのバイトを破棄しなければなりません。）
A Receiver that has partially received an SNDU (in the Current SNDU buffer) MUST check the PUSI value in the header of all subsequent TS Packets with the same PID (i.e., same TS Logical Channel). If it receives a TS Packet with a PUSI value of 1, it MUST then verify the Payload Pointer. If the Payload Pointer does NOT equal the number of bytes remaining to complete the Current SNDU (i.e., the difference between the SNDU Length field and the number of reassembled bytes), the Receiver has detected a delimiting error.
部分（現在SNDU緩衝液中）SNDUを受信した受信機は、同じPID（すなわち、同じTS論理チャネル）とそれ以降のすべてのTSパケットのヘッダ内のPUSI値をチェックしなければなりません。それは1のPUSI値とTSパケットを受信した場合、それは、次に、ペイロードポインタを確認しなければなりません。ペイロードポインタは、現在のSNDUを完了するために残っているバイトの数と等しくない場合（即ち、SNDU Lengthフィールドと再組み立てバイトの数との差）は、受信機は、区切り誤りを検出しました。
Following a delimiting error, the Receiver MUST discard the partially assembled SNDU (in the Current SNDU buffer) and SHOULD record a reassembly error. It MUST then re-enter the Idle State.
区切りのエラーの後、レシーバは、（現在のSNDUバッファに）部分的に組み立てられたSNDUを捨てなければなりませんし、再構築エラーを記録する必要があります。その後、アイドル状態を再入力する必要があります。
The Receiver SHOULD check the MPEG-2 Transport Error Indicator carried in the TS Packet header [ISO-MPEG2]. This flag indicates a transmission error for a TS Logical Channel. If the flag is set to a value of one, a transmission error event SHOULD be recorded. Any partially received SNDU MUST be discarded. The Receiver then enters the Idle State.
受信機は、TSパケットヘッダ[ISO-MPEG2]で運ばMPEG2トランスポートエラーインジケータを確認してください。このフラグは、TS論理チャネルのための伝送エラーを示します。フラグが1の値に設定されている場合、伝送エラーイベントが記録されるべきです。どれでも部分的に受信SNDUを捨てなければなりません。受信機は、アイドル状態に入ります。
The Receiver MUST check the MPEG-2 Continuity Counter carried in the TS Packet header [ISO-MPEG2]. If two (or more) successive TS Packets within the same TS Logical Channel carry the same Continuity Counter value, the duplicate TS Packets MUST be silently discarded. If the received value is NOT identical to that in the previous TS Packet, and it does NOT increment by one for successive TS Packets (modulo 16), the Receiver has detected a continuity error. Any partially received SNDU MUST be discarded. A continuity counter error event SHOULD be recorded. The Receiver then enters the Idle State.
受信機は、TSパケットヘッダ[ISO-MPEG2]で運ばMPEG2継続カウンタをチェックしなければなりません。同じTS内の2つ（またはそれ以上）の連続したTSパケットは、論理チャネルが同じ連続性カウンタ値を運ぶ場合は、重複したTSパケットは黙って捨てなければなりません。受信された値が以前のTSパケット内のものと同一ではない、そしてそれは、連続するTSパケットのための1つの（モジュロ16）によって増分されない場合、受信機は、連続エラーを検出しました。どれでも部分的に受信SNDUを捨てなければなりません。連続性カウンタのエラーイベントが記録されるべきです。受信機は、アイドル状態に入ります。
Note that an MPEG2-2 Transmission network is permitted to carry duplicate TS Packets [ISO-MPEG2], which are normally detected by the MPEG-2 Continuity Counter. A Receiver that does not perform the above Continuity Counter check would accept duplicate copies of TS Packets to the reassembly procedure. In most cases, the SNDU CRC-32 integrity check will result in discard of these SNDUs, leading to unexpected PDU loss; however, in some cases, duplicate PDUs (fitting into one TS Packet) could pass undetected to the next layer protocol.
MPEG2-2伝送ネットワークは、通常、MPEG2継続カウンタによって検出された重複するTSパケット[ISO-MPEG2]を、運ぶために許可されていることに注意してください。上記の連続性カウンタのチェックを実行しないレシーバは、再組み立て手順にTSパケットの重複コピーを受け入れるだろう。ほとんどの場合、SNDU CRC-32整合性チェックは、予期しないPDUの損失につながる、これらSNDUsの破棄になります。しかし、いくつかの場合には、次のレイヤプロトコルに未検出渡すことができる（1つのTSパケットにフィット）PDUを重複。
This document defines a Unidirectional Lightweight Encapsulation (ULE) that performs efficient and flexible support for IPv4 and IPv6 network services over networks built upon the MPEG-2 Transport Stream (TS). The encapsulation is also suited to transport of other protocol packets and bridged Ethernet frames.
この文書では、MPEG-2トランスポートストリーム（TS）上に構築されたネットワーク上にIPv4とIPv6ネットワークサービスのための効率的で柔軟なサポートを行う一方向軽量カプセル化（ULE）を定義します。カプセル化は、他のプロトコルパケットの輸送に適しており、イーサネットフレームをブリッジ。
ULE also provides an Extension Header format and defines an associated IANA registry for efficient and flexible support of both mandatory and optional SNDU headers. This allows for future extension of the protocol, while providing backwards compatibility with existing implementations. In particular, Optional Extension Headers may safely be ignored by Receivers that do not implement them, or choose not to process them.
ULEはまた、拡張ヘッダのフォーマットを提供し、必須および任意SNDUヘッダの両方の効率的で柔軟性のサポートのために、関連するIANAレジストリを定義します。既存の実装との下位互換性を提供しながら、これは、プロトコルの将来の拡張を可能にします。具体的には、オプションの拡張ヘッダーには、安全にそれらを実装する、またはそれらを処理しないことを選択していない受信機では無視することができます。
This document is based on a previous document authored by: Horst D. Clausen, Bernhard Collini-Nocker, Hilmar Linder, and Gorry Fairhurst. The authors wish to thank the members of the ip-dvb mailing list for their input; in particular, the many comments received from Art Allison, Carstsen Borman, Patrick Cipiere, Wolgang Fritsche, Hilmar Linder, Alain Ritoux, and William Stanislaus. Alain also provided the original examples of usage.
ホルスト・D.クラウゼン、ベルンハルトCollini-Nocker、ヒルマーリンダー、およびGorry Fairhurst：この文書は、著前の文書に基づいています。作者は彼らの入力のためのIP-DVBメーリングリストのメンバーに感謝したいです。特に、多くのコメントがアートアリソン、Carstsenボーマン、パトリックCipiere、Wolgang Fritsche、ヒルマーリンダー、アランRitoux、ウィリアムスタニスラウスから受け取りました。アランはまた、使用の元の例を提供しました。
The security considerations for ULE resemble those that arise when the existing Multi-Protocol Encapsulation (MPE) is used. ULE does not add specific new threats that will impact the security of the general Internet.
ULEのためのセキュリティの考慮事項は、既存のマルチプロトコルカプセル化（MPE）を使用しているときに発生するものに似ています。 ULEは、一般的なインターネットのセキュリティに影響を与える特定の新たな脅威に追加されません。
There is a known security issue with un-initialised stuffing bytes. In ULE, these bytes are set to 0xFF (normal practice in MPEG-2).
未初期化スタッフィングバイトと既知のセキュリティ上の問題があります。 ULEでは、これらのバイトは、0xFFの（MPEG-2における通常の慣行）に設定されています。
There are known integrity issues with the removal of the LAN FCS in a bridged networking environment. The removal for bridged frames exposes the traffic to potentially undetected corruption while being processed by the Encapsulator and/or Receiver.
ブリッジネットワーク環境でのLAN FCSの除去に関する既知の整合性の問題があります。ブリッジフレームのための除去は、エンカプスレータおよび/または受信機によって処理されている間潜在未検出腐敗へのトラフィックを公開します。
There is a potential security issue when a Receiver receives a PDU with two Length fields: The Receiver would need to validate the actual length and the Length field and ensure that inconsistent values are not propagated by the network. In direct encapsulation of IPv4/IPv6 in ULE, this is avoided by including only one SNDU Length
レシーバは、2つの長さフィールドでPDUを受信潜在的なセキュリティ問題があります：レシーバは、実際の長さと長さフィールドを検証し、一貫性のない値がネットワークによって伝播されないことを確認する必要があります。 ULEでのIPv4 / IPv6の直接カプセル化では、これは、ただ1つのSNDUの長さを含むことによって回避されます
Field. However, this issue still arises in bridged LLC frames, and frames with a LLC Length greater than the SNDU payload size MUST be discarded, and an SNDU payload length error SHOULD be recorded.
フィールド。しかし、この問題は依然としてブリッジLLCフレーム内に生じ、SNDUペイロードサイズよりも大きいLLC長でフレームが廃棄されなければならない、とSNDUペイロード長エラーが記録されるべきです。
In the future, a ULE Mandatory Extension Header may be used to define a method to perform link encryption of the SNDU payload. This is as an additional security mechanism to IP-, transport-, or application-layer security, not a replacement [RFC4259]. The approach is generic and decouples the encapsulation from future security extensions. The operation provides functions that resemble those currently used with the MPE encapsulation.
将来的には、ULE必須拡張ヘッダは、SNDUペイロードのリンク暗号化を実行する方法を定義するために使用されてもよいです。これは、追加のセキュリティIP-に機構、transport-、またはアプリケーション層セキュリティではなく、置換[RFC4259]の通りです。アプローチは、一般的なものと将来のセキュリティ拡張からカプセルを分離します。操作は、現在MPEカプセル化で使用されるものに似ている機能を提供します。
Additional security control fields may be provided as part of this link encryption Extension Header, e.g., to associate an SNDU with one of a set of Security Association (SA) parameters. As a part of the encryption process, it may also be desirable to authenticate some or all of the SNDU headers. The method of encryption and the way in which keys are exchanged is beyond the scope of this specification, as are the definition of the SA format and that of the related encryption keys.
追加のセキュリティ制御フィールドは、セキュリティアソシエーション（SA）パラメータのセットの1つでSNDUを関連付けるために、例えば、このリンク暗号化拡張ヘッダの一部として提供することができます。暗号化プロセスの一環として、また、SNDUヘッダの一部またはすべてを認証することが望ましい場合があります。 SAフォーマットの定義及び関連の暗号鍵とされているような暗号化と鍵を交換する方法の方法は、本明細書の範囲外です。
The IANA has created the ULE Next-Header Type field registry as defined in this document.
この文書で定義されるようにIANAは、ULE次-ヘッダタイプフィールドのレジストリを作成しました。
ULE Next-Header registry
ULE次-ヘッダーレジストリ
This registry allocates Next-Header values within the range 0-511 (decimal). For each allocated value, it also specifies the set of allowed H-LEN values (see section 5). In combination, these define a set of allowed values in the range 0-1535 for the first part of the ULE Type space (see section 4.4.1).
このレジストリは、範囲0から511（10進数）内の次のヘッダ値を割り当てます。割り当てられた各値のために、それはまた、許容H-LEN値（セクション5を参照）のセットを指定します。組合せにおいて、これらは、ULEタイプ空間の最初の部分の範囲は0から1535で許可される値のセットを定義する（セクション4.4.1を参照）。
The following contains the IANA guidelines for management of the ULE Next-Header registry. This registry allocates values 0-511 decimal (0x0000-0x01FF, hexadecimal). It MUST NOT allocate values greater than 0x01FF (decimal).
以下は、ULE次-ヘッダーレジストリの管理のためのIANAガイドラインが含まれています。このレジストリは、値が0から511小数（0x0000-0x01FF、16進数）を割り当てます。これは、0x01FF（10進数）以上の値を割り当ててはなりません。
It subdivides the Next-Header registry in the following way:
それは次のように次のヘッダレジストリを細分化：
1) 0-255 (decimal) IANA-assigned values, indicating Mandatory Extension Headers (or link-dependent Type fields) for ULE, requiring expert review leading to prior issue of an IETF RFC. This specification MUST define the value and the name associated with the Extension Header, together with the procedure for processing the Extension Header. It MUST also define the need for the Mandatory Extension and the intended use. The size of the Extension Header MUST be specified.
1）ULEための必須拡張ヘッダー（またはリンクに依存タイプフィールドを示す0〜255（10進数）IANAによって割り当てられた値は、）、IETF RFCの前に問題をもたらす専門家レビューを必要とします。この仕様は、一緒に拡張ヘッダを処理するための手順と、拡張ヘッダに関連付けられた値と名前を定義しなければなりません。また、必須の拡張の必要性や、使用目的を定義しなければなりません。拡張ヘッダのサイズを指定する必要があります。
Assignments have been made in this document, and registered by IANA:
割り当ては、このドキュメントで行われ、IANAによって登録されています：
Type Name Reference
名前参照を入力
0: Test-SNDU Section 5.1 1: Bridged-SNDU Section 5.2
0：TEST-SNDUセクション5.1：1架橋SNDU 5.2節
2) 256-511 (decimal) IANA-assigned values, indicating Optional Extension Headers for ULE, requiring expert review leading to prior issue of an IETF RFC. This specification MUST define the value and the name associated with the Extension Header, together with the procedure for processing the Extension Header. The entry MUST specify the range of allowable H-LEN values that are permitted (in the range 1-5). It MUST also define the need for the Optional Extension and the intended use.
2）256から511（10進数）IANAによって割り当てられた値を、IETF RFCの前に問題をもたらす専門家レビューを必要ULEのオプション拡張ヘッダを示します。この仕様は、一緒に拡張ヘッダを処理するための手順と、拡張ヘッダに関連付けられた値と名前を定義しなければなりません。エントリは、（範囲1-5）許可される許容H-LEN値の範囲を指定しなければなりません。また、オプションの拡張および意図された使用の必要性を定義しなければなりません。
Assignments have been made in this document, and registered by IANA:
割り当ては、このドキュメントで行われ、IANAによって登録されています：
Type Name H-LEN Reference
名前H-LEN参照を入力
256: Extension-Padding 1-5 Section 5.3
256：拡張-パディング1-5 5.3節
[ISO-MPEG2] IS 13818-1, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", International Standards Organisation (ISO), 2000.
、国際標準化機構（ISO）、2000：[ISO-MPEG2]は13818-1は、 "システム - - 映画と関連オーディオ情報のジェネリックコーディングパート1情報技術" です。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112、1989年8月 "IPマルチキャスティングのためのホスト拡大"。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットのトランスミッション"、RFC 2464、1998年12月。
[ULE1] Registration for format_identifier ULE1, SMPTE Registration Authority, LLC, http://www.smpte-ra.org/ule1.html.
[ULE1] format_identifier ULE1、SMPTE登録機関、LLC、http://www.smpte-ra.org/ule1.htmlの登録。
[IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution for IP datagrams over MPEG-2 Networks", Work in Progress, September 2005.
[IPDVB-AR] Fairhurst、G.およびM-J。 Montpetit、「MPEG-2ネットワーク上のIPデータグラムのためのアドレス解決」、進歩、2005年9月での作業。
[ATSC] A/53, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53 Rev.C, 2004
[ATSC] / 53、 "ATSCデジタルテレビジョン規格"、高度テレビジョンシステム委員会（ATSC）、ドク。 / 53 Rev.C、2004
[ATSC-DAT] A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/090, 2000.
[ATSC-DAT] A / 90、 "ATSCデータ放送規格"、高度テレビジョンシステム委員会（ATSC）、ドク。 A / 090、2000。
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/91, 2001.
[ATSC-DATG] A / 91、：、高度テレビジョンシステム委員会（ATSC）、ドク "推奨プラクティスATSCデータ放送基準の適用指針"。 / 91、2001。
[ATSC-G] A/54, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54, 1995.
[ATSC-G]、高度テレビジョンシステム委員会（ATSC）、ドキュメント/ 54 A、 "ATSCデジタルテレビジョン規格の使用に関するガイド"。 / 54、1995。
[ATSC-PSIP-TC] A/65B, "Program and System Information Protocol for Terrestrial Broadcast and Cable", Advanced Television Systems Committee (ATSC), Doc. A/65B, 2003.
、高度テレビジョンシステム委員会（ATSC）、ドク[ATSC-PSIP-TC] A / 65B、 "地上波放送とケーブルのためのプログラムとシステム情報プロトコル"。 A / 65B、2003。
[ATSC-REG] ATSC "Code Point Registry" www.atsc.org/standards/Code_Point_Registry.pdf.
[ATSC-REG] ATSC "コードポイントレジストリ" www.atsc.org/standards/Code_Point_Registry.pdf。
[ATSC-S] A/80, "Modulation and Coding Requirements for Digital TV (DTV) Applications over Satellite", Advanced Television Systems Committee (ATSC), Doc. A/80, 1999.
[ATSC-S] A / 80、 "変調およびデジタルTV（DTV）衛星経由のアプリケーションのコーディング要件"、高度テレビジョンシステム委員会（ATSC）、ドク。 / 80、1999。
[DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet Local Area Network Specification" Version 2.0, November 1982.
[DIX]ディジタルイクイップメント社、インテル社、ゼロックス社、「イーサネットローカルエリアネットワーク仕様」バージョン2.0、1982年11月。
[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI), 2004.
[ETSI-DAT] EN 301 192、欧州電気通信標準化機構（ETSI）、2004、 "データ放送の仕様"。
[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV)", European Telecommunications Standards Institute (ETSI), 1998.
300 800、EN [ETSI-DVBC] "デジタルビデオ放送（DVB）;ケーブルテレビ配信システム（CATV）用DVB対話チャンネル"、欧州電気通信標準化機構（ETSI）、1998。
[ETSI-DVBS] EN 300 421, "Digital Video Broadcasting (DVB); Modulation and Coding for DBS satellite systems at 11/12 GHz", European Telecommunications Standards Institute (ETSI), 1997.
300 421 EN [ETSI-DVBS]、 "デジタルビデオ放送（DVB）; 11/12 GHzでDBS衛星システムのための変調および符号化"、欧州電気通信標準化機構（ETSI）、1997。
[ETSI-DVBT] EN 300 744, "Digital Video Broadcasting (DVB); Framing structure, channel coding and modulation for digital terrestrial television (DVB-T)", European Telecommunications Standards Institute (ETSI), 2004.
[ETSI-DVBT] EN 300 744、 "デジタルビデオ放送（DVB）;地上デジタルテレビジョン（DVB-T）のためのフレーミング構造、チャネル符号化及び変調"、欧州電気通信標準化機構（ETSI）、2004。
[ETSI-RCS] ETSI 301 790, "Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems", European Telecommunications Standards Institute (ETSI), 2005.
[ETSI-RCS] ETSI 301 790、 "デジタルビデオ放送（DVB）;衛星配信システムのための対話チャンネル"、欧州電気通信標準化機構（ETSI）、2005。
[IEEE-802.2] IEEE 802.2, "Local and metropolitan area networks-Specific requirements Part 2: Logical Link Control", IEEE Computer Society, (also ISO/IEC 8802-2), 1998.
[IEEE-802.2] IEEE 802.2、 "ローカルおよびメトロポリタンエリアネットワーク固有の要件パート2：論理リンク制御"、IEEEコンピュータ学会、（また、ISO / IEC 8802-2）、1998。
[IEEE-802.3] 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 Computer Society, (also ISO/IEC 8802-3), 2002.
[IEEE-802.3] IEEE 802.3、「ローカルおよびメトロポリタンエリアネットワーク固有の要件パート3：衝突検出（CSMA / CD）アクセス方式および物理層仕様とキャリア検知多重アクセス」、IEEEコンピュータ学会、（また、ISO / IEC 8802 -3）、2002。
[ISO-DSMCC] IS 13818-6, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 6: Extensions for DSM-CC", International Standards Organisation (ISO), 1998.
[ISO-DSMCC]は、13818-6 IS "情報技術 - 映画と関連オーディオ情報のジェネリックコーディング - パート6：DSMCC用拡張機能"、国際標準化機構（ISO）、1998。
[ITU-H222] H.222.0, "Information technology - Generic coding of moving pictures and associated audio information: Systems", International Telecommunication Union, (ITU-T), 1995.
[ITU-H222] H.222.0、 "情報技術 - 動画の一般的な符号化と関連したオーディオ情報：システム"、国際電気通信連合（ITU-T）、1995。
[ITU-3563] I.363.5, "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", International Telecommunication Union, (ITU-T), 1996.
[ITU-3563] I.363.5、 "B-ISDN ATMアダプテーションレイヤ仕様：タイプ5 AAL"、国際電気通信連合（ITU-T）、1996。
[ISO-8802-2] ISO/IEC 8802.2, "Logical Link Control", International Standards Organisation (ISO), 1998.
[ISO-8802-2] ISO / IEC 8802.2、 "論理リンク制御"、国際標準化機構（ISO）、1998。
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, March 2001.
[RFC3077] DUROS、E.、Dabbous、W.、Izumiyama、H.、藤井、N.、およびY.チャン、 "単方向リンクのリンク層トンネル機構"、RFC 3077、2001年3月。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309]石、J.、スチュワート、R.、およびD.オーティス、 "ストリーム制御伝送プロトコル（SCTP）チェックサムの変更"、RFC 3309、2002年9月。
[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月。
[SOOR05] M. Sooriyabandara, G. Fairhurst, A. Ang, B. Collini-Nocker, H. Linder, W. Stering "A Lightweight Encapsulation Protocol for IP over MPEG-2 Networks: Design, Implementation and Analysis", Computer Networks 48 p5-19, 2005.
[SOOR05] M. Sooriyabandara、G. Fairhurst、A.アン、B. Collini-Nocker、H.リンダー、W. Stering "MPEG-2ネットワーク上のIPのための軽量カプセル化プロトコル：設計、実装と分析"、コンピュータネットワーク48 p5-19、2005。
Appendix A: SNDU Packing Examples
付録A：SNDUパッキングの例
This appendix provides some examples of use. The appendix is informative. It does not provide a description of the protocol. The examples provide the complete TS Packet sequence for some sample encapsulated IP packets.
この付録では、多少の使用例を示します。付録は有益です。これは、プロトコルの記述を提供していません。例として、いくつかのサンプルカプセル化されたIPパケットのための完全なTSパケット列を提供します。
The specification of the TS Packet header operation and field values is provided in [ISO-MPEG2]. The specification of ULE is provided in the body of this document.
TSパケットヘッダ動作およびフィールド値の指定は[ISO-MPEG2]で提供されます。 ULEの仕様は、このドキュメントの本体に設けられています。
The key below is provided for the following examples.
以下のキーは、以下の例のために提供されます。
HDR 4B TS Packet Header PUSI Payload Unit Start Indicator PP Payload Pointer *** TS Packet Payload Pointer (PP)
HDR 4B TSパケットヘッダPUSIペイロードユニットスタートインジケータPPペイロードのポインタ*** TSパケットのペイロード・ポインタ（PP）
Example A.1: Two 186B PDUs.
例A.1：二186BのPDU。
SNDU A is 200 bytes (including the ULE destination NPA address) SNDU B is 200 bytes (including the ULE destination NPA address)
SNDU Aは、SNDU Bは（ULE宛先NPAアドレスを含む）200バイトである（ULE宛先NPAアドレスを含む）200バイトであります
The sequence comprises 3 TS Packets:
シーケンスは、3つのTSパケットを含みます：
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * *
*****
SNDU
PP=17 CRC for A Length
+-----+------+------+- -+--- --+------+------+- -+------+
| HDR | 0x11 | A183 | ... | A199 | 0x00 | 0xC4 | ... | B165 |
+-----+----*-+------+- -+------+-*----+------+- -+------+
PUSI=1 * *
*************************
End Stuffing
CRC for A Indicator Bytes
+-----+------+- -+------+----+----+- -+----+
| HDR | B166 | ... | B199 |0xFF|0xFF| ... |0xFF|
+-----+------+- -+------+----+----+- -+----+
PUSI=0
Example A.2: Usage of last byte in a TS-Packet
例A.2：TS-パケットの最後のバイトの使い方
SNDU A is 183 bytes SNDU B is 182 bytes SNDU C is 181 bytes SNDU D is 185 bytes
SNDU Aは、SNDU Dが185バイトである181バイトSNDU Bは182バイトSNDU Cである183バイトであります
The sequence comprises 4 TS Packets:
シーケンスは、4つのTSパケットを含みます。
SNDU
PP=0 Length CRC for A
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xB3 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * *
*****
SNDU Unused
PP=0 Length CRC for B byte
+-----+------+------+------+- -+------+------+
| HDR | 0x00 | 0x00 | 0xB2 | ... | B181 | 0xFF |
+-----+---*--+-*----+------+- -+------+------+
PUSI=1 * *
******
SNDU SNDU
PP=0 Length CRC for C Length
+-----+------+------+------+- -+------+------+------+
| HDR | 0x00 | 0x00 | 0xB1 | ... | C180 | 0x00 | 0x65 |
+-----+---*--+-*----+------+- -+------+------+------+
PUSI=1 * *
****** Unused
byte
+-----+------+- -+------+------+
| HDR | D002 | ... | D184 | 0xFF |
+-----+------+- -+------+------+
PUSI=0
Example A.3: Large SNDUs
例A.3：大SNDUs
SNDU A is 732 bytes SNDU B is 284 bytes
SNDU Aは、SNDU Bは284バイトで732バイトであります
The sequence comprises 6 TS Packets:
シーケンスは6つのTSパケットを含みます：
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x02 | 0xD8 | ... | A182 |
+-----+---*--+-*----+------+- -+------+
PUSI=1 * *
******
+-----+------+- -+------+
| HDR | A183 | ... | A366 |
+-----+------+- -+------+
PUSI=0
+-----+------+- -+------+
| HDR | A367 | ... | A550 |
+-----+------+- -+------+
PUSI=0
SNDU
PP=181 CRC for A Length
+-----+------+------+- -+------+------+------+
| HDR | 0xB5 | A551 | ... | A731 | 0x01 | 0x18 |
+-----+---*--+------+- -+------+*-----+------+
PUSI=1 * *
*************************
+-----+------+- -+------+
| HDR | B002 | ... | B185 |
+-----+------+- -+------+
PUSI=0
End Stuffing
Indicator Bytes
+-----+------+- -+------+------+------+- -+------+
| HDR | B186 | ... | B283 | 0xFF | 0xFF | ... | 0xFF |
+-----+------+- -+------+------+------+- -+------+
PUSI=0
Example A.4: Illustration of SNDU Length field
例A.4：SNDUの長さフィールドのイラスト
SNDU A is 200 bytes SNDU B is 60 bytes SNDU C is 60 bytes
SNDU Aは、SNDU Bは、SNDU Cが60バイトで60バイトで200バイトであります
The sequence comprises two TS Packets:
シーケンスは2つのTSパケットを含みます：
SNDU
PP=0 Length
+-----+------+------+------+- -+------+
| HDR | 0x00 | 0x00 | 0xC4 | ... | A182 |
+-----+----*-+-*----+------+- -+------+
PUSI=1 * * + +
***** ++++++++
+
+++++++++++++++++
+ SNDU
PP=17 CRC for A + Length
+-----+------+------+- -+------+-+----+------+-
| HDR | 0x11 | A183 | ... | A199 | 0x00 | 0x38 | ...
+-----+----*-+------+- -+------+*-----+------+-
PUSI=1 * * + +
************************ +++++++++
+
+++++++++++++++++++++++++++++++++++++++
+
+ SNDU End Stuffing
+ Length Indicator bytes
+ -+------+------+------+ -+------+------+------+- -+------+
+ ... | B59 | 0x00 | 0x38 |...| C59 | 0xFF | 0xFF |...| 0xFF |
+ -+------+-+----+------+ -+------+-+----+------+- -+------+
+ + + + +
+ + ++++++++ +
+ + + +
++++++++++++++++ ++++++++++++++++++++++
*** TS Packet Payload Pointer (PP) +++ ULE Length Indicator
*** TSパケットペイロードポインタ（PP）+++ ULE長さインジケータ
Example A.5: Three 44B PDUs.
例A.5：三台の44BのPDU。
SNDU A is 52 bytes (no ULE destination NPA address) SNDU B is 52 bytes (no ULE destination NPA address) SNDU C is 52 bytes (no ULE destination NPA address)
SNDU Aは52バイト（NO ULE宛先NPAアドレス）SNDU Bは52バイト（NO ULE宛先NPAアドレス）SNDU Cは52バイト（NO ULE宛先NPAアドレス）であります
The sequence comprises 1 TS Packet:
シーケンスは1つのTSパケットを含みます：
SNDU
PP=0 Length
+-----+------+------+------+- -+-----+------+------+- -+-----+-
| HDR | 0x00 | 0x80 | 0x30 | ... | A51 | 0x80 | 0x30 | ... | B51 | ..
+-----+----*-+-*----+------+- -+-----+------+------+- -+-----+-
PUSI=1 * *
*****
End Stuffing
Indicator bytes
-----+------+- -+-----+---------+- -+------+
... 0x80 | 0x30 | ... | C51 |0xFF|0xFF| | 0xFF |
-----+------+- -+-----+---------+- -+------+
Appendix B: SNDU Encapsulation
付録B：SNDUカプセル化
An example of ULE encapsulation carrying an ICMPv6 packet generated by ping6.
ping6によって生成のICMPv6パケットを運ぶULEカプセル化の例。
ULE SNDU Length : 63 decimal D-bit value : 0 (NPA destination address present) ULE Protocol Type : 0x86dd (IPv6) Destination ULE NPA Address : 00:01:02:03:04:05 ULE CRC32 : 0x7c171763
ULE SNDUの長さ：63進Dビットの値：0（NPA宛先アドレス本）ULEプロトコルタイプ：0x86dd（IPv6）の宛先ULE NPAアドレス：00：01：02：03：04：05 ULE CRC32：0x7c171763
Source IPv6 : 2001:DB8:3008:1965::1 Destination IPv6 : 2001:DB8:2509:1962::2
送信元IPv6：2001：DB8：3008：1965 :: 1つの宛先のIPv6：2001：DB8：2509：1962 :: 2
SNDU contents (including CRC-32):
（CRC-32を含む）SNDU内容：
0000: 00 3f 86 dd 00 01 02 03 04 05 60 00 00 00 00 0d 0016: 3a 40 20 01 0d b8 30 08 19 65 00 00 00 00 00 00 0032: 00 01 20 01 0d b8 25 09 19 62 00 00 00 00 00 00 0048: 00 02 80 00 9d 8c 06 38 00 04 00 00 00 00 00 7c 0064: 17 17 63
0000：DD 00 01 02 03 04 05 60 00 00 00 00 0D 0016 00 3F 86：3A 40 20 01 30 08 19 65 00 00 00 00 00 00 0032 0DのB8：00 01 20 01 0DのB8 25 09 19 62 00 00 00 00 00 00 0048 00 02 80 00 9D 8C 06 38 00 04 00 00 00 00 00 7（c）0064：17 17 63
Authors' Addresses
著者のアドレス
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK
アバディーン、AB24 3UE英国のエンジニアリング大学のGodred Fairhurst部門
EMail: gorry@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/Gorry
メールアドレス：gorry@erg.abdn.ac.ukウェブ：http://www.erg.abdn.ac.uk/users/Gorry
Bernhard Collini-Nocker Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria
ザルツブルクヤコブHaringer筋力の科学計算大学のベルンハルトCollini-Nocker部門。 2 5020ザルツブルクオーストリア
EMail: bnocker@cosy.sbg.ac.at Web: http://www.scicomp.sbg.ac.at/
メールアドレス：ウェブbnocker@cosy.sbg.ac.at：http://www.scicomp.sbg.ac.at/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。