[要約] RFC 4326は、MPEG-2トランスポートストリーム（TS）上でIPデータグラムを転送するための単方向軽量カプセル化（ULE）についての仕様です。このRFCの目的は、IPデータグラムを効率的にMPEG-2 TSに組み込むためのプロトコルを提供することです。
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).
Copyright（c）The Internet Society（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 Transport Stream（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.
このドキュメントでは、IPv4およびIPv6データグラムおよびその他のネットワークプロトコルパケットの輸送のための単方向の軽量カプセル化（ULE）メカニズムについて、ISO MPEG-2トランスポートストリームをTSプライベートデータとして直接説明します。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 MPEG-2トランスポートストリーム[ISO-MPEG2、RFC4259]を介したIPデータグラムまたはその他のネットワーク層パケットの輸送のカプセル化について説明します。カプセル化は、[RFC4259]のセクション4で定義されている軽量カプセル化の要件を満たします。基本ヘッダーは、必要なプロトコルフィールドセットを提供します。拡張ヘッダーも定義できます。このヘッダー構造は、DSM-CCテーブルセクションの構文[ISO-DSMCC]）の上に構築される現在の代替方法（例：MPE [ETSI-DAT]）よりも解析および処理[SOOR05]を解析して処理するのが大幅に簡単です。
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]、衛星TV [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.
MPEG-2トランスポートマルチプレックスを介した送信に使用される、イーサネットフレーム、IPデータグラム、またはその他のネットワーク層パケットなどのプロトコルデータユニット（PDU）は、エンコープレーターに渡されます。これにより、各PDUは、カプセル化ヘッダーと整合性チェックトレーラーを追加することにより、サブネットワークデータユニット（SNDU）にフォーマットします。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).
MPEG-2仕様[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値がule [ule1]に登録されています。この32ビット数の16進数は0x554C4531です。ISO 13818-1 [ISO-MPEG2]で定義されているプログラムマップテーブル（PMT）を利用し、このドキュメントで定義されているULE形式を使用するトランスポートストリームは、PMT ES_INFO DESCRIPTORループにこの値を持つ記述子を挿入するはずです。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 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].
この情報により、受信機と再マルチプレクサー[RFC4259]が特定のULEストリーム（つまり、ULEストリームを運ぶTS論理チャネルのPID値）を特定することができます。この情報が必要な条件とそれが提供される形式は、このドキュメントの範囲を超えています。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].
このドキュメントの「必須」、「必要」、「必須」、「必要」、「shall」、「shall "、" sulld "、" low "of"、 "bulsed"、 "becomperded"、 "optional」[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].
適応フィールド：MPEG-2マルチプレックス[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.
DSM-CC：デジタルストレージメディアコマンドとコントロール[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：デジタルビデオ放送。ISO MPEG-2を使用したデータ、データの送信のための、欧州通信標準研究所（ETSI）（例えば[ETSI-DVBC、ETSI-DVBS、ETSI-DVBT]）が発行する関連標準のフレームワークとセット標準[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.
Encapsurator：PDUを受信し、これらをTSパケットのストリームとして出力のペイロードユニット（ここではSNDUSとして知られている）にフォーマットするネットワークデバイス。
End Indicator: A value that indicates to the Receiver that there are no further SNDUs present within the current TS Packet.
エンドインジケーター：現在のTSパケット内にそれ以上のsndusが存在しないことを受信機に示す値。
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]のリンク層ヘッダー。6Bの宛先アドレス、6Bソースアドレス、2Bタイプフィールドで構成されています（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]。PDUをカプセル化し、DSM-CCテーブルセクションを形成するスキーム。各セクションは、単一の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]).
MPEG-2：Motion Picture Experts Group（MPEG）によって指定され、International Standards Organization（ISO/IEC 13818-1）[ISO-MPEG2]およびITU-T（H.222 [ITU]によって標準化された一連の標準セット-H222]）。
Next-Header: A Type value indicating an Extension Header.
Next-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送信ネットワーク内の6バイトの宛先アドレス（IEEE MACアドレスに似ています）を指します。
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.
梱包のしきい値：エンコープカプレーターが、パディングを使用するのではなく、より多くのSNDUを蓄積するために、部分的に満たされた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 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.
PID：パケット識別子[ISO-MPEG2]。TSパケットのヘッダーにある13ビットフィールド。これは、TSパケットが属するTS論理チャネルを識別するために使用されます[ISO-MPEG2]。テーブルセクション、PES、またはその他のペイロードユニットの部分を形成するTSパケットは、すべて同じPID値を持つ必要があります。All-Zeros PID 0x0000およびその他のPID値は、特定のPSI/SIテーブル[ISO-MPEG2]に予約されています。すべてのPID値0x1FFFは、TSマルチプレックスの一定のビットレートを維持するために導入されたNULL 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つ以上の基本的なストリーム、特定のMPEG-2プログラム、または輸送ストリーム全体に関連する個人情報（つまり、[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マルチプレックスで運ばれるサービスに関する情報を伝えるために使用されるテーブル。情報は、MPEG-2 [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では、1に設定されたPusiビットは、1バイトのペイロードポインター（PP）の存在も示しています。
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マルチプレックスで運ばれるサービスに関する情報を伝えるために別の標準団体によって定義されているテーブルについて説明しています。テーブルは、1つ以上のテーブルセクションで構成されている場合があります。ただし、特定のSIテーブルのすべてのセクションは、単一のTS論理チャネル[ISO-MPEG2]を搭載する必要があります。
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：TSパケットを使用したMPEG-2レベルでの伝送方法であるTransport Stream [ISO-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)
If the PUSI bit is set to a value of 1, there is one additional field following the TS packet header:
pusiビットが1の値に設定されている場合、TSパケットヘッダーに続く1つの追加フィールドがあります。
*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論理チャネル：輸送ストリーム論理チャネル。このドキュメントでは、この用語はMPEG-2レベル[ISO-MPEG2]でチャネルを識別します。ISO/OSI参照モデルのレベル2に存在します。TS論理チャネルを介して送信されるすべてのパケットは、同じPID値を持ちます（この値は特定のTSマルチプレックス内で一意です）。「ストリーム」という用語は、MPEG-2 [ISO-MPEG2]で定義されており、特定のTS論理チャネルによって運ばれるコンテンツを記述します（ULE Streamを参照）。一部の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 Multiplex：このドキュメントでは、この用語では、単一の低層接続で送信されたMPEG-2 TS論理チャネルのセットを定義します。これは、一般的な物理リンク（つまり、指定されたシンボルレート、FEC設定、および伝送周波数での伝送）または別のプロトコル層（例：イーサネット、またはIPを介したRTP）によって提供されるカプセル化などです。同じTS論理チャネルは、複数のTSマルチプレックス（おそらく異なるPID値に関連付けられている可能性がある）で繰り返される場合があります[RFC4259]。たとえば、同じマルチキャストコンテンツを2つの陸生テレビ伝送セルに再配布します。
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]を介して送信されたデータの固定長18B単位。各TSパケットには、4Bヘッダーに加えて、適応フィールド、暗号化の詳細、タイムスタンプ情報を含むオプションのオーバーヘッドが搭載されており、関連するTS論理チャネルのセットを同期します。
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ストリーム：ULEカプセル化されたPDUのみを搭載したMPEG-2 TS論理チャネル。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は、単一のTSパケットのペイロードに配置されるか、必要に応じて一連のTSパケットに断片化することにより、MPEG-2トランスミッションネットワーク上に送信されます。十分なスペースがある場合、この方法では、単一のTSパケットが複数のSNDU（またはその一部）を運ぶことができます。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パケットペイロード内の少なくとも1つのペイロードユニット（SNDU）の開始を示します。PUSIビットのセマンティクスは、PESおよびPSIパケット[ISO-MPEG2]で定義されています。プライベートデータの場合、その使用は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;
0：TSパケットにはSNDUの開始が含まれていませんが、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パケットペイロードの終了前に終了するが、別のペイロードユニットを起動することを意図していない場合、詰め物の手順（パディングと呼ばれる）は、TSパケットペイロードの残りのバイトを値0xffで埋めます[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パケットのペイロードは、値0x00のペイロードポインターから始まり、次のペイロードユニットがTSパケットヘッダーのすぐ後に続くことを示します。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パケットは、AFC値「01」で送信する必要があります。ULEをサポートするTS論理チャネルの場合、受信機は他の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はULEを使用してSNDUを形成するカプセル化されています。（各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.
ULEのすべてのマルチバイト値（長さ/端インジケーター（4.2,4.3）、タイプ（4.4）、宛先アドレス（4.5）、および拡張ヘッダー（5）を含む）は、ネットワークバイトの順序で送信されます（最初に最も重要なバイト）。各バイトの最も重要なビットは、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.
長さフィールドの最も重要なビットは、フィールド、D-BITの不在である宛先アドレスの値を持ちます。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).
Dビット値1でエンドインジケータ（4.3）を送信する必要があります。他のSNDUは、0または1のDビット値で送信できます。）。
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ベースヘッダーのタイプフィールド（図9）に続いてCRCまでのバイトからカウントされたSNDUの長さを示す15ビット値。この長さには、存在する可能性のあるエクステンションヘッダーのサイズが含まれます（セクション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を持っている場合、これはエンドインジケーターを示します（つまり、すべての長さがDビット値1の1と組み合わされます）。これは、現在のTSパケット内にそれ以上のsndusが存在しないこと（セクション6を参照）、および宛先アドレスフィールドが存在しないことをレシーバーに示します。値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で運ばれるペイロードのタイプ、または次のヘッダーの存在を示します。このフィールドに割り当てられる値のセットは、イーサネットの割り当てと同様に、2つの部分に分割されます。
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.
倫理はもともと、イーサネットV2仕様[DIX]の下でXeroxによって指定されていました。IEEE 802.3 [IEEE-802.3、ISO-8802-2]の指定後、1536（0x0600）未満のeterytypesのセットが長さの指標の役割を引き受けました。イーサネットレシーバーは、この機能を使用して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を受信する場合、潜在的な曖昧なケースがあります。レシーバーは、実際の長さと長さフィールドを検証し、一貫性のない値がネットワークによって伝播されないことを確認する必要があります。したがって、2つの独立した長さフィールドの仕様は望ましくありません。ULEヘッダーでは、これは1つの長さの値のみを含めることによりSNDUヘッダーで回避されますが、LLCフレームの橋渡しはこの考慮事項を再導入します（セクション5.2）。
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形式は常に明示的な長さフィールドを保持するため、Ethernet LLCの識別モードはULEでは必要ありません。したがって、以下のように、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タイプフィールド値の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:
タイプ空間の最初の部分は、値0〜1535小数に対応します。これらの値を使用して、リンク固有のプロトコルを識別したり、追加のオプションプロトコルフィールド（ブリッジングカプセル化など）を運ぶ拡張ヘッダーの存在を示すために使用できます。これらの値の使用は、IANAレジストリによって調整されます。次のタイプは、このドキュメントで定義されています。
0x0000: Test SNDU (see section 5.1) 0x0001: Bridged Frame (see section 5.2) 0x0100: Extension-Padding (see section 5.3)
0x0000：SNDUをテストする（セクション5.1を参照）0x0001：ブリッジフレーム（セクション5.2を参照）0x0100：拡張パッジング（セクション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用に定義された値を使用する必要があります。次の2つのタイプ値は、例として使用されます（IANA ETHERTYPESレジストリから取得）：
0x0800: IPv4 Payload (see section 4.7.2) 0x86DD: IPv6 Payload (see section 4.7.3)
0x0800：IPv4ペイロード（セクション4.7.2を参照）0x86DD：IPv6ペイロード（セクション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）。送信者は、差別装置フィールド（例えば、IPv4/IPv6宛先アドレス、またはブリッジ付きMAC宛先アドレス）を利用できるレシーバーに配信されるIPユニキャストパケットおよび/またはマルチキャストパケットについて、このフィールド（d = 1）を省略できます。これは、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の宛先アドレスは、通常、16進数で表される6バイト番号で、受信したSNDUを処理するMPEG-2伝送ネットワークの受信機を識別するために使用されます。値0x00：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リンクブロードキャストアドレス（0xff：ff：ff：ff：ff）に設定する必要があります。
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グループ宛先アドレスをマルチキャストSNDU宛先アドレスにマッピングする必要があります（宛先MACアドレスを生成するために使用される方法に従ってくださいイーサネット内）。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多項式を使用します。この多項式が採用されている例には、イーサネット、DSM-CCセクション構文[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].
カプセレータは、CRC-32アキュムレータレジスタを値0xFFFF FFFFに初期化します。次に、SNDUヘッダーの開始からSNDUの終わりまでのすべてのバイト（CRC-32を保持している32ビットトレーラーを除く）を含むCRC32の送信値を蓄積し、これをCRCフィールドに配置します。ULEでは、バイトはSNDU内の位置を増やす順に処理されます。BITSの処理順序は逆になりません。この使用は似ていますが、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を持っていないSNDUは破棄され、レシーバーがアイドル状態に入ります。
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).
このCRCの主な目的は、SNDUがMPEG-2サブネットワークを横切って、および/または処理中にSNDUが輸送中に予期しないソフトウェア/ハードウェア操作によって導入された検出されない再組み立てエラーとエラーから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タイプフィールドの組み合わせによって決定されます。最も単純なカプセル化は、PDUを直接SNDUペイロードに入れます。一部のタイプ1のカプセルでは、追加のヘッダーフィールドが必要になる場合があります。これらは、NPA宛先アドレスの後にSNDUに挿入され、PDUの直前に挿入されます。
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）。Bridged 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.
ENDインジケータの形式を図2に示します。この形式は、Dビット値1を持つ必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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データグラムは、2つの標準SNDU構造のいずれかを使用して直接輸送され、PDUは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データグラムは、2つの標準SNDU構造のいずれかを使用して直接輸送され、PDUは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では、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バイトが必要です。これは、単純化された処理と、拡張機能が存在しない場合の一般的なケースの単純な軽量ヘッダーの維持に基づいて正当化されます。
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型フィールドとして編成されています。
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 Next-Headerフィールドの構造
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のオプションの拡張ヘッダーを示します（タイプのみ）長さ8b（タイプ6b）5のヘッダーは、長さ10b（タイプ8b）のオプションの拡張ヘッダーを示します
>=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型の値は、このタイプフィールドに直接従う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タイプは、256の必須ヘッダー拡張機能のいずれかまたは256のオプションヘッダー拡張機能のいずれかである1バイトフィールドです。両方のタイプの拡張ヘッダーの現在許可されている値のセットは、IANAレジストリによって定義されます（セクション15）。オプションの拡張機能のレジストリ値は、h = 1（すなわち、範囲256-511の小数点）で指定されますが、範囲1〜5のHより長さの値で使用できます（セクション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と拡張パッジングの使用です。テストSNDUの必須拡張ヘッダーは、PDU全体が破棄されることになります。拡張パッジングオプションエクステンションヘッダーは、次の（ある場合）オプションヘッダーが無視されます（つまり、合計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：1つの拡張ヘッダーを使用したSNDUカプセル化（d = 0の場合）
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です（この例D = 0では、拡張ヘッダーを使用する場合はNPAアドレスも省略できます）。T1はベースヘッダータイプフィールドです。この場合、次のヘッダー値を指定します。H1は、ヘッダータイプT1用に定義された一連のフィールドです。特定のULE拡張ヘッダーには、0バイト以上の情報がある場合があります。T2は、次のヘッダーのタイプフィールド、または運ばれる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の倫理を示す値を超える値があります。SNDUには任意の数の連続した拡張ヘッダーが含まれている場合がありますが、SNDUが一般に多数の拡張機能を搭載することは予想されません。
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）は、タイプ1の必須エクステンションヘッダーです。このヘッダーは、SNDUのヘッダーチェーンで指定された最終的な（またはのみ）拡張ヘッダーでなければなりません。このSNDUのデータ部分の構造は、このドキュメントで定義されていません。受信者はログファイルに受信を記録する場合がありますが、テストSNDUを破棄する必要があります。D-BITは、テスト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.
Bridged SNDUは、タイプ1の必須拡張ヘッダーです。これは、SNDUのヘッダーチェーンで指定された最終的な（またはのみ）拡張ヘッダーでなければなりません。ペイロードには、MACアドレスとEtherType [DIX]またはLLC長[ISO-8802-2]フィールドとブリッジ付きMACフレームの内容が含まれます。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宛先アドレスを運ぶすべてのSNDUを破棄する必要があります。残りのSNDUのペイロードは、以下のブリッジングルールによって処理されます。NPAアドレスのないSNDU（d = 1）により、受信者はすべて受信したSNDUのペイロードでブリッジ処理を実行します。
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-Lengthを含むブリッジエクステンションヘッダーを備えた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).
フレームのEtherType/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.
この特別なケースでは、必須の拡張ヘッダー形式は、ETHERTYPE [DIX]またはIEEE 802 [IEEE-802.3]によって指定されたLLC長さフィールドのいずれかとして解釈される場合があります。イアナ。
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 FCで受信したフレームは破棄する必要があります。チェック後、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型値で指定されています。他のオプションの拡張機能と同様に、拡張機能の総長さはH-Lenフィールド（16ビット語で指定）で示されます。拡張フィールドは、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ビットフィールドは、次のヘッダータイプフィールドを形成します。受信者はタイプフィールドを解釈する必要がありますが、この拡張ヘッダーの他のフィールドを無視する必要があります。
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にヘッダーとトレーラーを追加することにより、SNDUに送信するためにキューにキューにキューを形成します（セクション4）。次に、SNDUを一連のTSパケットペイロードに分割します（図13）。これらは、TSマルチプレックスを介して単一のTS論理チャネルを使用して送信されます。TSマルチプレックスは、最終的に受信機に配信される前に、多数のMPEG-2（RE）マルチプレクサによって処理される場合があります[RFC4259]。
+------+--------------------------------+------+
| 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：SNDUの一連のTSパケットへのカプセル化
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.
Encapsulatorが以前に特定のTS論理チャネル用にTSパケットを送信していない場合、またはアイドル期間後には、最初の使用可能なTSパケットでSNDUを送信し始めます。生成されたこの最初のTSパケットは、1のPUSI値を搭載する必要があります。また、ゼロのペイロードポインター値を持つ必要があり、TSパケットペイロードのペイロードポインターの直後にSNDUが起動することを示します。
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パケットがTSパケットヘッダーに運ばれるMPEG-2連続性カウンターを設定することを保証する必要があります。この値は、同じTS論理チャネルを使用して送信されたフラグメント/完全なSNDUを含む、連続するTSパケットごとに1つ（Modulo 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パケットペイロードにこれ以上のSNDUがないことを受信機に通知します。エンドインジケーターの後に、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パケットペイロードの次の利用可能なbyteを使用して、以前にカプセル化されたSNDUを別のSNDUで追跡できます（6.2を参照）。これは梱包と呼ばれます（図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.)
(i) TSパケットに残りのスペースがない場合、EncapsuratorはこのTSパケットを送信します。新しいTSパケットで次のSNDUの送信を開始します。（標準ルール[ISO-MPEG2]では、この新しいTSパケットのヘッダーが1のPUSI値を持ち、その後に0x00のペイロードポインター値を持つことを要求しています。）
(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.)
（ii）SNDUの最終部分を運ぶTSパケットに未使用のペイロードの1つのバイトがある場合、エンカプサーはこの最終バイトに0xFFを配置し、TSパケットを送信する必要があります。このルールは、TSパケットにPUSIセットがないときに発生する可能性のある複雑な動作を解決するための簡単なメカニズムを提供します。それ以外の場合は、現在のTSパケットに別のSNDUを送信するには、TSパケットペイロードの最後のバイトを消費するペイロードポインターを追加する必要があります。動作は、他のMPEG-2ペイロードタイプ[ISO-DSMCC]について同様の慣行に従います。カプセレータは、新しいTSパケットで次のSNDUの送信を開始する必要があります。（標準ルールでは、この新しいTSパケットのヘッダーが1のPUSI値を運ぶ必要があります。その後、ペイロードポインター値は0x00です。）
(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.)
（iii）SNDUの最終部分を運ぶTSパケットに正確に2バイトの未使用のペイロードがあり、PUSIがまだ設定されていない場合、エンカプセーターはこれらの最後の2バイトに0xffffを配置する必要があり、エンドインジケーターを提供する必要があります（セクション4.3）、およびTSパケットを送信します。このルールは、2つのTSパケットにわたるSNDU長いフィールドの断片化を防ぎます。カプセレータは、新しいTSパケットで次のSNDUの送信を開始する必要があります。（標準ルールでは、この新しいTSパケットのヘッダーが1のPUSI値を運ぶ必要があります。その後、ペイロードポインター値は0x00です。）
(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.)
（iv）TSパケットの未使用のペイロードが2バイト以上の場合、エンカプセーターはこの部分的に完全な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 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).
(v) TSパケットペイロードのSNDUデータで少なくとも2つのバイトが利用可能である場合（つまり、PUSIが以前に設定されていない場合は3バイト、以前に設定されていた場合は2バイト）、エンカプセーターは次の開始してさらにキューに囲まれたPDUをカプセル化する場合があります。現在のTSパケットペイロードの次の利用可能なバイトのSNDU。EncapsuratorがPUSIがまだ設定されていないTSパケットにさらにsndusを梱包する場合、PUSIを更新する必要があり（1に設定）、TSパケットヘッダーの直後に8ビットペイロードポインターを最初のバイトに挿入する必要があります。。（これにより、1バイトでデータに使用できるTSパケットペイロードフィールドのサイズが削減されます。）ペイロードポインターの値は、TSパケットペイロードの最初のSNDUの終わりに続いてバイトの位置に設定する必要があります。それ以上のPDUが利用できない場合、カプセレーターは、追加のPDUが不完全なTSパケットを入力するのを待つ場合があります。パッキングのしきい値として知られるエンコイプレーターが待つことができる最大期間は、境界を築く必要があり、カプセレータで構成可能である必要があります。パッキングしきい値内でTSパケットを完了するのに十分な追加のPDUが受信されない場合、エンコプセーターはエンドインジケーターを挿入する必要があります（ルール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パケットペイロードのサイズよりも少ない場合、1つのPUSI値とエンドインジケーター（ルールIVを使用）を持つTSパケットが形成される場合があります。
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論理チャネルに関連付けられており、SNDUのストリームを形成するために再組み立てされています。単一のレシーバーは、おそらくさまざまな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.
PUSI値が1の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の梱包方法とパディング方法の両方の使用をサポートし、宛先アドレスフィールドの有無にかかわらずSNDUの受信をサポートする必要があります（つまり、d = 0およびd = 1）。
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.
アイドル状態のレシーバーは、受信したすべてのTSパケットのヘッダーのPUSI値を確認する必要があります。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長さフィールドを読み取ります。値が4以下、または0xffffに等しい場合、受信機は現在の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バッファーへのバイトを受け入れます。）。現在のSNDUの長さが長さフィールドの値に等しい場合、受信機はCRC値を計算して検証する必要があります（4.6を参照）。無効なCRC値を含むSNDUは破棄する必要があります。CRCの不一致はエラーイベントであり、CRCエラーとして記録する必要があります。基礎となる物理層処理（例：フォワードエラー補正コーディング）は、多くの場合、単一のビットエラーではなくエラーのパターンをもたらすため、受信者は、TSパケットとペイロードに対する腐敗のarbitrary意的なパターンに対して堅牢である必要があります。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）、受信者はレシーバーによって指定されたアドレスのセットの1つに一致するSNDUを受け入れます（これには、受信者のNPAアドレス、NPAブロードキャストアドレス、および必要なマルチキャストNPAアドレスが含まれます）。レシーバーは、比類のないアドレスで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ペイロードは、指定された次のプロトコル層に渡されます。未知のタイプ値<1536を持つSNDUを破棄する必要があります。このエラーイベントは、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.
(i) 現在のSNDUがTSパケットペイロードの終わりに終了した場合、受信者はアイドル状態に入る必要があります。
(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）現在のSNDUが完了した後、TSパケットペイロードに1つのバイトのみが処理されていない場合、受信者はこの最終バイトの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 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.)
（iii）TSパケットペイロードデータの2バイト以上が現在のSNDUの完了後に残っている場合、受信者は次の2バイトを受け入れ、これがエンドインジケータであるかどうかを調べます。エンドインジケーターを受信すると、受信者はTSパケットペイロードの残りの部分を静かに破棄し、アイドル状態に移行する必要があります。それ以外の場合は、これが次の梱包されたSNDUの開始であり、受信機はこのSNDUを処理することで継続します。（これは、TSパケットのPUSI値が1で、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値を確認する必要があります。PUSI値が1のTSパケットを受信した場合、ペイロードポインターを検証する必要があります。ペイロードポインターが残りのバイト数に等しくない場合、現在のSNDU（つまり、SNDU長さフィールドと再組み立てバイト数の差）の差）を完了した場合、受信機は削除エラーを検出しました。
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]に掲載されたMPEG-2輸送エラーインジケーターを確認する必要があります。このフラグは、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]で運ばれるMPEG-2連続性カウンターを確認する必要があります。同じTS論理チャネル内の2つの（またはそれ以上）連続したTSパケットが同じ連続性カウンター値を持つ場合、重複するTSパケットは静かに廃棄する必要があります。受信した値が以前のTSパケットのそれと同一ではなく、連続したTSパケット（Modulo 16）の場合は1つずつ増加しない場合、レシーバーは連続性エラーを検出しました。部分的に受け取った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トランスミッションネットワークは、通常、MPEG-2連続性カウンターによって検出される重複したTSパケット[ISO-MPEG2]を携帯することが許可されていることに注意してください。上記の連続性カウンターチェックを実行しないレシーバーは、TSパケットの重複コピーを再組み立て手順に受け入れます。ほとんどの場合、SNDU CRC-32の整合性チェックにより、これらのSNDUが破棄され、予期しないPDU損失が発生します。ただし、場合によっては、重複したPDU（1つのTSパケットに適合）が次のレイヤープロトコルに検出されずに通過する可能性があります。
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.
このドキュメントは、Horst D. Clausen、Bernhard Collini-Nocker、Hilmar Linder、およびGorry Fairhurstが作成した以前のドキュメントに基づいています。著者は、IP-DVBメーリングリストのメンバーに入力について感謝したいと考えています。特に、Art Allison、Carstsen Borman、Patrick Cipiere、Wolgang Fritsche、Hilmar Linder、Alain Ritoux、William Stanislausから受け取った多くのコメント。Alainは、使用法の元の例も提供しました。
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 FCの除去には既知の整合性の問題があります。ブリッジ型フレームの削除は、エンコープカプレータやレシーバーによって処理されている間、トラフィックを潜在的に検出されない腐敗にさらします。
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 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.
受信機が2つの長さフィールドを持つPDUを受信する場合、潜在的なセキュリティの問題があります。レシーバーは、実際の長さと長さフィールドを検証し、ネットワークによって一貫性のない値が伝播されないことを確認する必要があります。ULEでのIPv4/IPv6の直接カプセル化では、これは1つのSNDUの長さフィールドのみを含めることで回避されます。ただし、この問題はBridged 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-、輸送、またはアプリケーション層セキュリティに対する追加のセキュリティメカニズムとしてです[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.
追加のセキュリティ制御フィールドは、このリンク暗号化拡張ヘッダーの一部として提供される場合があります。たとえば、SNDUをセキュリティアソシエーション（SA）パラメーターのセットの1つに関連付けることができます。暗号化プロセスの一部として、SNDUヘッダーの一部またはすべてを認証することも望ましい場合があります。暗号化の方法とキーが交換される方法は、SA形式の定義と関連する暗号化キーの定義と同様に、この仕様の範囲を超えています。
The IANA has created the ULE Next-Header Type field registry as defined in this document.
IANAは、このドキュメントで定義されているように、ULE Next-Header Typeフィールドレジストリを作成しました。
ULE Next-Header registry
ULE Next-Headerレジストリ
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（小数）内で次のヘッダー値を割り当てます。割り当てられた値ごとに、許可された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 Next-Headerレジストリの管理に関するIANAガイドラインが含まれています。このレジストリには、値0-511小数（0x0000-0x01ff、16進数）が割り当てられます。0x01ff（小数）を超える値を割り当ててはなりません。
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) 0-255（小数）IANAが割り当てられた値は、ULEの必須拡張ヘッダー（またはリンク依存型フィールド）を示し、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
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（小数）IANAが割り当てられた値は、ULEのオプションの拡張ヘッダーを示し、IETF RFCの事前発行につながる専門家のレビューを必要とします。この仕様では、拡張ヘッダーに関連付けられた値と名前を、拡張ヘッダーの処理手順とともに定義する必要があります。エントリは、許可されている許容H-LEN値の範囲（1〜5の範囲）を指定する必要があります。また、オプションの拡張機能と意図した使用の必要性を定義する必要があります。
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-MPEG2]は13818-1、「情報技術 - 移動写真と関連するオーディオ情報の一般的なコーディング - パート1：システム」、国際標準組織（ISO）、2000。
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、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]フェアハースト、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] A/53、「ATSC Digital Television Standard」、Advanced Television Systems Committee（ATSC）、Doc。A/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 Data Broadcast Standard」、Advanced Television Systems Committee（ATSC）、Doc。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データブロードキャスト標準の実装ガイドライン」、Advanced Television Systems Committee（ATSC）、Doc。A/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] A/54、「ATSCデジタルテレビ標準の使用ガイド」、Advanced Television Systems Committee（ATSC）、Doc。A/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-PSIP-TC] A/65B、「地上放送およびケーブルのプログラムおよびシステム情報プロトコル」、Advanced Television Systems Committee（ATSC）、Doc。A/65b、2003年。
[ATSC-REG] ATSC "Code Point Registry" www.atsc.org/standards/Code_Point_Registry.pdf.
[atsc-Reg] atsc "code point registry" 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）アプリケーションの変調およびコーディング要件」、Advanced Television Systems Committee（ATSC）、Doc。A/80、1999。
[DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet Local Area Network Specification" Version 2.0, November 1982.
[DIX] Digital Equipment Corp、Intel Corp、Xerox Corp、「イーサネットローカルエリアネットワーク仕様」バージョン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.
[ETSI-DVBC] EN 300 800、「デジタルビデオブロードキャスト（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.
[ETSI-DVBS] EN 300 421、「デジタルビデオ放送（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です。
[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、「情報技術 - 移動写真と関連するオーディオ情報の一般的なコーディング：システム」、International Telecommunication Union、（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"、International Telecommunication Union、（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.、Fujii、N。、およびY. Zhang、「単方向リンクのためのリンク層トンネルメカニズム」、RFC 3077、2001年3月。
[RFC3309] Stone, J., Stewart, R., and D. Otis, "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002.
[RFC3309] Stone、J.、Stewart、R。、およびD. Otis、「Stream Control Transmission Protocol（SCTP）Checkum Change」、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. Linder、「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。Ang、B。Collini-Nocker、H。Linder、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)
Example A.1: Two 186B PDUs.
例A.1：2つの186b pdus。
SNDU A is 200 bytes (including the ULE destination NPA address) SNDU B is 200 bytes (including the ULE destination NPA address)
SNDU Aは200バイト（ULE宛先NPAアドレスを含む）SNDU Bは200バイト（ULE宛先NPAアドレスを含む）です
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
SNDU A is 183 bytes SNDU B is 182 bytes SNDU C is 181 bytes SNDU D is 185 bytes
sndu aは183バイトですsndu bは182バイトですsndu cは181バイトですsndu dは185バイトです
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は732バイトですsndu bは284バイトです
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は200バイトですsndu bは60バイトですsndu cは60バイトです
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
Example A.5: Three 44B PDUs.
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バイト（ULE宛先NPAアドレスなし）SNDU Bは52バイト（ULE宛先NPAアドレスなし）SNDU Cは52バイト（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
Source IPv6 : 2001:DB8:3008:1965::1
Destination IPv6 : 2001:DB8:2509:1962::2
SNDU contents (including CRC-32):
SNDUコンテンツ（CRC-32を含む）：
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：00 3F 86 DD 00 01 02 03 04 05 60 00 00 00 00 00 00 0D 0016：3A 40 20 01 0D B8 30 08 19 65 00 00 00 00 00 00 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000 00 00 00 0048：00 02 80 00 9d 8c 06 38 00 04 00 00 00 00 00 7C 0064：17 17 63
Authors' Addresses
著者のアドレス
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK
ゴッドレッドフェアハースト工科大学アバディーン大学アバディーン大学、AB24 3UE UK
EMail: gorry@erg.abdn.ac.uk
Web: 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
ベルンハルト・コリーニ・ノッカー科学コンピューティング局ザルツブルク大学ヤコブ・ハリンジャーSTR。2 5020 Salzburg Austria
EMail: bnocker@cosy.sbg.ac.at
Web: http://www.scicomp.sbg.ac.at/
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。