[要約] RFC 4259は、MPEG-2ネットワーク上でIPデータグラムを転送するためのフレームワークを提供しています。このRFCの目的は、MPEG-2ネットワーク上でのIPデータグラムの効率的な転送を実現することです。
Network Working Group M.-J. Montpetit
Request for Comments: 4259 Motorola Connected Home Solutions
Category: Informational G. Fairhurst
University of Aberdeen
H. Clausen
TIC Systems
B. Collini-Nocker
H. Linder
University of Salzburg
November 2005
A Framework for Transmission of IP Datagrams over MPEG-2 Networks
MPEG-2ネットワークを介したIPデータグラムを送信するためのフレームワーク
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document describes an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams (TS). The MPEG-2 TS has been widely accepted not only for providing digital TV services but also as a subnetwork technology for building IP networks. Examples of systems using MPEG-2 include the Digital Video Broadcast (DVB) and Advanced Television Systems Committee (ATSC) Standards for Digital Television.
このドキュメントでは、ISO MPEG-2トランスポートストリーム（TS）を介したIPデータグラムの輸送のアーキテクチャについて説明しています。MPEG-2 TSは、デジタルTVサービスを提供するだけでなく、IPネットワークを構築するためのサブネットワークテクノロジーとしても広く受け入れられています。MPEG-2を使用したシステムの例には、デジタルビデオブロードキャスト（DVB）およびAdvanced Television Systems Committee（ATSC）のデジタルテレビの基準が含まれます。
The document identifies the need for a set of Internet standards defining the interface between the MPEG-2 Transport Stream and an IP subnetwork. It suggests a new encapsulation method for IP datagrams and proposes protocols to perform IPv6/IPv4 address resolution, to associate IP packets with the properties of the Logical Channels provided by an MPEG-2 TS.
このドキュメントは、MPEG-2トランスポートストリームとIPサブネットワークとの間のインターフェイスを定義する一連のインターネット標準の必要性を特定しています。IPデータグラムの新しいカプセル化方法を提案し、IPv6/IPv4アドレス解像度を実行するプロトコルを提案し、IPパケットをMPEG-2 TSによって提供される論理チャネルのプロパティと関連付けます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Salient Features of the Architecture .......................4
2. Conventions Used in This Document ...............................4
3. Architecture ....................................................8
3.1. MPEG-2 Transmission Networks ...............................8
3.2. TS Logical Channels .......................................10
3.3. Multiplexing and Re-Multiplexing ..........................12
3.4. IP Datagram Transmission ..................................13
3.5. Motivation ................................................14
4. Encapsulation Protocol Requirements ............................16
4.1. Payload Unit Delimitation .................................17
4.2. Length Indicator ..........................................18
4.3. Next Level Protocol Type ..................................19
4.4. L2 Subnet Addressing ......................................19
4.5. Integrity Check ...........................................21
4.6. Identification of Scope. ..................................21
4.7. Extension Headers .........................................21
4.8. Summary of Requirements for Encapsulation .................22
5. Address Resolution Functions ...................................22
5.1. Address Resolution for MPEG-2 .............................23
5.2. Scenarios for MPEG AR .....................................25
5.2.1. Table-Based AR over MPEG-2 .........................25
5.2.2. Table-Based AR over IP .............................26
5.2.3. Query/Response AR over IP ..........................26
5.3. Unicast Address Scoping ...................................26
5.4. AR Authentication .........................................27
5.5. Requirements for Unicast AR over MPEG-2 ...................28
6. Multicast Support ..............................................28
6.1. Multicast AR Functions ....................................29
6.2. Multicast Address Scoping .................................30
6.3. Requirements for Multicast over MPEG-2 ....................31
7. Summary ........................................................31
8. Security Considerations ........................................32
8.1. Link Encryption ...........................................33
9. IANA Considerations ............................................34
10. Acknowledgements ..............................................34
11. References ....................................................34
11.1. Normative References .....................................34
11.2. Informative References ...................................34
Appendix A ........................................................39
This document identifies requirements and an architecture for the transport of IP Datagrams over ISO MPEG-2 Transport Streams [ISO-MPEG]. The prime focus is the efficient and flexible delivery of IP services over those subnetworks that use the MPEG-2 Transport Stream (TS).
このドキュメントは、ISO MPEG-2トランスポートストリームを介したIPデータグラムの輸送の要件とアーキテクチャを特定しています[ISO-MPEG]。主な焦点は、MPEG-2トランスポートストリーム（TS）を使用するサブネットワークよりもIPサービスの効率的かつ柔軟な配信です。
The architecture is designed to be compatible with 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 typically provide unidirectional (simplex) physical and link layer standards, and have been defined for a wide range of physical media (e.g., Terrestrial TV [ETSI-DVBT, ATSC-PSIP-TC], Satellite TV [ETSI-DVBS, ETSI-DVBS2, ATSC-S], Cable Transmission [ETSI-DVBC, ATSC-PSIP-TC, OPEN-CABLE], and data transmission over MPEG-2 [ETSI-MHP].
アーキテクチャは、MPEG-2、たとえばデジタルビデオブロードキャスト（DVB）アーキテクチャ、Advanced Television Systems Committee（ATSC）システム[ATSC、ATSC-G]、およびその他のMPEG-2ベースの伝送システムなど、MPEG-2に基づくサービスと互換性があるように設計されています。このようなシステムは通常、単方向（シンプレックス）物理レイヤー標準とリンク層標準を提供し、幅広い物理メディア（例えば、陸生テレビ[ETSI-DVBT、ATSC-PSIP-TC]、衛星TV [ETSI-DVBS、ETSI-DVBS2、ATSC-S]、cable Transmission [eTSI-DVBC、ATSC-PSIP-CABLE]を定義しています。 HP]。
+-+-+-+-+------+------------+---+--+--+---------+
|T|V|A|O| O | | O |S |O | |
|e|i|u|t| t | | t |I |t | |
|l|d|d|h| h | IP | h | |h | Other |
|e|e|i|e| e | | e |T |e |protocols|
|t|o|o|r| r | | r |a |r | native |
|e| | | | | | |b | | over |
|x| | | | | +---+----+-+ |l | |MPEG-2 TS|
|t| | | | | | | MPE | |e | | |
| | | | | +--+---+ +------+ | | | |
| | | | | | AAL5 |ULE|Priv. | | | | |
+-+-+-+-+---+------+ | +-+--+--+ |
| PES | ATM | |Sect. |Section| |
+-------+----------+---+------+-------+---------+
| MPEG-2 TS |
+---------+-------+----------------+------------+
|Satellite| Cable | Terrestrial TV | Other PHY |
+---------+-------+----------------+------------+
Figure 1: Overview of the MPEG-2 protocol stack
図1：MPEG-2プロトコルスタックの概要
Although many MPEG-2 systems carry a mixture of data types, MPEG-2 components may be, and are, also used to build IP-only networks. Standard system components offer advantages of improved interoperability and larger deployment. However, some MPEG-2 networks do not implement all parts of a DVB / ATSC system, and may, for instance, support minimal, or no, signalling of Service Information (SI) tables.
多くのMPEG-2システムにはデータ型が混在していますが、MPEG-2コンポーネントはIPのみのネットワークの構築にも使用される場合があります。標準システムコンポーネントは、相互運用性の向上と展開の大幅な利点を提供します。ただし、一部のMPEG-2ネットワークでは、DVB / ATSCシステムのすべての部分を実装するわけではなく、たとえば、サービス情報（SI）テーブルのシグナル伝達を最小限に抑える、またはNOをサポートする場合があります。
The architecture defined in this document describes a set of protocols that support transmission of IP packets over the MPEG-2 TS. Key characteristics of these networks are that they may provide link-level broadcast capability, and that many supported applications require access to a very large number of subnetwork nodes.
このドキュメントで定義されているアーキテクチャは、MPEG-2 TS上のIPパケットの送信をサポートする一連のプロトコルについて説明しています。これらのネットワークの主要な特性は、リンクレベルのブロードキャスト機能を提供する可能性があり、サポートされている多くのアプリケーションには非常に多数のサブネットワークノードへのアクセスが必要であることです。
Some, or all, of these protocols may also be applicable to other subnetworks, e.g., other MPEG-2 transmission networks, regenerative satellite links [ETSI-BSM], and some types of broadcast wireless links. The key goals of the architecture are to reduce complexity when using the system, while improving performance, increasing flexibility for IP services, and providing opportunities for better integration with IP services.
これらのプロトコルのいくつかまたはすべては、他のサブネットワーク、例えば他のMPEG-2トランスミッションネットワーク、再生衛星リンク[ETSI-BSM]、およびいくつかの種類の放送ワイヤレスリンクにも適用できる場合があります。アーキテクチャの重要な目標は、システムを使用するときに複雑さを減らし、パフォーマンスを向上させ、IPサービスの柔軟性を高め、IPサービスとのより良い統合の機会を提供することです。
Since a majority of MPEG-2 transmission networks are bandwidth-limited, encapsulation protocols must therefore add minimal overhead to ensure good link efficiency while providing adequate network services. They also need to be simple to minimize processing, robust to errors and security threats, and extensible to a wide range of services.
したがって、MPEG-2伝送ネットワークの大部分は帯域幅制限であるため、カプセル化プロトコルは、適切なネットワークサービスを提供しながら、良好なリンク効率を確保するために最小限のオーバーヘッドを追加する必要があります。また、処理を最小限に抑え、エラーやセキュリティの脅威に堅牢で、幅広いサービスに拡張可能である必要があります。
In MPEG-2 systems, TS Logical Channels, are identified by their PID and provide multiplexing, addressing, and error reporting. The TS Logical Channel may also be used to provide Quality of Service (QoS). Mapping functions are required to relate TS Logical Channels to IP addresses, to map TS Logical Channels to IP-level QoS, and to associate IP flows with specific subnetwork capabilities. An important feature of the architecture is that these functions may be provided in a dynamic way, allowing transparent integration with other IP-layer protocols. Collectively, these will form an MPEG-2 TS Address Resolution (AR) protocol suite [IPDVB-AR].
MPEG-2システムでは、TS論理チャネルがPIDによって識別され、多重化、アドレス指定、およびエラーレポートが提供されます。TS論理チャネルは、品質（QOS）を提供するためにも使用できます。マッピング関数は、TS論理チャネルをIPアドレスに関連付け、TS論理チャネルをIPレベルのQoSにマッピングし、IPフローを特定のサブネットワーク機能に関連付けるために必要です。アーキテクチャの重要な特徴は、これらの機能が動的な方法で提供され、他のIP層プロトコルとの透明な統合を可能にすることです。まとめて、これらはMPEG-2 TSアドレス解像度（AR）プロトコルスイート[IPDVB-AR]を形成します。
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-MPEG].
適応フィールド：MPEG-2マルチプレックス[ISO-MPEG]に詰め込んでいるだけでなく、クロック参照とタイミングと同期情報を伝達することを目的とした、固定長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 [ISO-MPEG].
ATSC：高度なテレビシステム委員会[ATSC]。ISO MPEG-2標準[ISO-MPEG]を使用したビデオ、オーディオ、およびデータの送信に関するフレームワークと一連の関連標準。
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for transmission of data and control information defined by the ISO MPEG-2 standard that is carried in an MPEG-2 Private Section.
DSM-CC：デジタルストレージメディアコマンドとコントロール[ISO-DSMCC]。MPEG-2プライベートセクションにあるISO MPEG-2標準によって定義されたデータと制御情報の送信のための形式。
DVB: Digital Video Broadcast [ETSI-DVBC, ETSI-DVBRCS, ETSI-DVBS]. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data, using the ISO MPEG-2 Standard [ISO-MPEG].
DVB：デジタルビデオ放送[ETSI-DVBC、ETSI-DVBRCS、ETSI-DVBS]。ISO MPEG-2標準[ISO-MPEG]を使用して、ビデオ、オーディオ、およびデータの送信のために、欧州通信標準研究所（ETSI）が発行した関連標準のフレームワークとセット。
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として知られている）にフォーマットするネットワークデバイス。
Forward Direction: The dominant direction of data transfer over a network path. Data transfer in the forward direction is called "forward transfer". Packets travelling in the forward direction follow the forward path through the IP network.
前方方向：ネットワークパス上のデータ転送の支配的な方向。前方向のデータ転送は「フォワード転送」と呼ばれます。前方向に移動するパケットは、IPネットワークを通るフォワードパスに従います。
MAC: Medium Access and Control. The link layer header of the Ethernet IEEE 802 standard of protocols, consisting of a 6B destination address, 6B source address, and 2B type field (see also NPA).
MAC：中程度のアクセスと制御。6Bの宛先アドレス、6Bソースアドレス、2Bタイプフィールドで構成されるイーサネットIEEE 802標準プロトコルのリンクレイヤーヘッダー（NPAも参照）。
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) [ISO-MPEG].
MPEG-2：Motion Picture Experts Group（MPEG）によって指定され、International Standards Organization（ISO）[ISO-MPEG]によって標準化された一連の標準。
NPA: Network Point of Attachment. Addresses primarily used for station (Receiver) identification within a local network (e.g., IEEE MAC address). An address may identify individual Receivers or groups of Receivers.
NPA：添付ファイルのネットワークポイント。アドレスは、主にローカルネットワーク内のステーション（レシーバー）識別に使用されます（例：IEEE MACアドレス）。住所は、個々の受信機または受信機のグループを識別する場合があります。
PAT: Program Association Table [ISO-MPEG]. An MPEG-2 PSI control table that associates program numbers with the PID value used to send the corresponding PMT. The PAT is sent using the well-known PID value of zero.
PAT：プログラムアソシエーションテーブル[ISO-MPEG]。対応するPMTを送信するために使用されるPID値とプログラム番号を関連付けるMPEG-2 PSI制御テーブル。PATは、よく知られているゼロ値を使用して送信されます。
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 Stream [ISO-MPEG]. A format of MPEG-2 TS packet payload usually used for video or audio information.
PES：パケット化された初等ストリーム[ISO-MPEG]。通常、ビデオまたはオーディオ情報に使用されるMPEG-2 TSパケットペイロードの形式。
PID: Packet Identifier [ISO-MPEG]. 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-MPEG]. The TS Packets forming the parts of a Table Section, PES, or other Payload Unit must all carry the same PID value. The all 1s PID value indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes.
PID：パケット識別子[ISO-MPEG]。TSパケットのヘッダーに搭載された13ビットフィールド。これは、TSパケットが[ISO-MPEG]に属するTS論理チャネルを識別するために使用されます。テーブルセクション、PES、またはその他のペイロードユニットの部分を形成するTSパケットは、すべて同じPID値を持つ必要があります。すべての1S PID値は、TSマルチプレックスの一定のビットレートを維持するために導入されたNULL TSパケットを示します。異なるTSマルチプレックスを使用して送信されるTS論理チャネルに使用されるPID値の間に必要な関係はありません。
PMT: Program Map Table. An MPEG-2 PSI control table that associates the PID values used by the set of TS Logical Channels/Streams that comprise a program [ISO-MPEG]. The PID value which is used to send the PMT for a specific program is defined by an entry in the PAT.
PMT：プログラムマップテーブル。プログラム[ISO-MPEG]を構成するTS論理チャネル/ストリームのセットで使用されるPID値を関連付けるMPEG-2 PSI制御テーブル。特定のプログラムのPMTを送信するために使用されるPID値は、PATのエントリによって定義されます。
PP: Payload Pointer [ISO-MPEG]. An optional one byte pointer that directly follows the TS Packet header. It contains the number of bytes between the end of the TS Packet header and the start of a Payload Unit. 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 and Table Sections; it is not present in TS Logical Channels that use the PES-format.
PP：ペイロードポインター[ISO-MPEG]。TSパケットヘッダーを直接追跡するオプションの1バイトポインター。TSパケットヘッダーの端とペイロードユニットの開始の間のバイト数が含まれています。ペイロードポインターの存在は、TSパケットヘッダーのPUSIビットの値によって示されます。ペイロードポインターは、DSM-CCおよびテーブルセクションに存在します。PES形式を使用するTS論理チャネルには存在しません。
Private Section: A syntactic structure constructed in accordance with Table 2-30 of [ISO-MPEG]. The structure may be used to identify private information (i.e., not defined by [ISO-MPEG]) relating to one or more elementary streams, or a specific MPEG-2 program, or the entire TS. 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-MPEG]の表2-30に従って構築された構文構造。構造は、1つ以上の基本的なストリーム、特定のMPEG-2プログラム、またはTS全体に関連する個人情報（つまり、[ISO-MPEG]で定義されていない）を識別するために使用できます。その他の標準団体（ETSI、ATSCなど）は、private_section構造を使用してテーブル構造のセットを定義しています。プライベートセクションは、TS論理チャネルを使用してTSパケットのシーケンスとして送信されます。TS論理チャネルには、複数のテーブルセットからセクションを搭載する場合があります。
PSI: Program Specific Information [ISO-MPEG]. PSI is used to convey information about services carried in a TS Multiplex. It is carried in one of four specifically identified table section constructs [ISO-MPEG], see also SI Table.
PSI：プログラム固有の情報[ISO-MPEG]。PSIは、TSマルチプレックスで運ばれるサービスに関する情報を伝えるために使用されます。特別に識別された4つのテーブルセクションコンストラクト[ISO-MPEG]のいずれかに掲載されています。SIテーブルも参照してください。
PU: Payload Unit. 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が含まれます。
PUSI: Payload_Unit_Start_Indicator [ISO-MPEG]. 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-mpeg]。TSパケットヘッダーに掲載された1つのビットフラグ。ゼロのpusi値は、TSパケットが新しいペイロードユニットの開始を運ばないことを示します。1つのpusi値は、TSパケットが新しいペイロードユニットの開始を運ぶことを示します。ULEでは、1に設定されたPusiビットも1バイトペイロードポインター（PP）の存在を示します。
Receiver: A piece of 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-MPEG]. In this document, this term describes a table that is used to convey information about the services carried in a TS Multiplex, that has been defined by another standards body. 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-MPEG].
SIテーブル：サービス情報テーブル[ISO-MPEG]。このドキュメントでは、この用語では、別の標準団体によって定義されているTSマルチプレックスで運ばれるサービスに関する情報を伝えるために使用されるテーブルについて説明しています。テーブルは1つ以上のテーブルセクションで構成されている場合がありますが、特定のSIテーブルのすべてのセクションは、単一のTS論理チャネル[ISO-MPEG]に携帯する必要があります。
SNDU: Sub-Network Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU：サブネットワークデータユニット。MPEG-2ペイロードユニットとして送信されたカプセル化されたPDU。
STB: Set-Top Box. A consumer equipment (Receiver) for reception of digital TV services.
STB：セットトップボックス。デジタルテレビサービスの受容のための消費者機器（受信機）。
Table Section: A Payload Unit carrying all or a part of an SI or PSI Table [ISO-MPEG].
表セクション：SIまたはPSIテーブルの全部または一部を運ぶペイロードユニット[ISO-MPEG]。
TS: Transport Stream [ISO-MPEG], a method of transmission at the MPEG-2 level using TS Packets; it represents level 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex.
TS：TSパケットを使用したMPEG-2レベルでの伝送方法であるTransport Stream [ISO-MPEG]。ISO/OSI参照モデルのレベル2を表します。TS論理チャネルとTSマルチプレックスも参照してください。
TS Header: The 4-byte header of a TS Packet [ISO-MPEG].
TSヘッダー：TSパケットの4バイトヘッダー[ISO-MPEG]。
TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO-MPEG]. 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). According to MPEG-2, some TS Logical Channels are reserved for specific signalling. Other standards (e.g., ATSC, DVB) also reserve specific TS Logical Channels.
TS論理チャネル：輸送ストリーム論理チャネル。このドキュメントでは、この用語はMPEG-2レベル[ISO-MPEG]のチャネルを識別します。ISO/OSI参照モデルのレベル2に存在します。TS論理チャネルを介して送信されるすべてのパケットは、同じPID値を持ちます（この値は特定のTSマルチプレックス内で一意です）。MPEG-2によると、一部のTS論理チャネルは特定のシグナル伝達のために予約されています。他の標準（ATSC、DVBなど）も特定のTS論理チャネルを予約しています。
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), 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値に関連付けられている可能性がある）で繰り返される場合があります。
TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex [ISO-MPEG]. Each TS Packet carries a 4B header, plus optional overhead including an Adaptation Field, encryption details and time stamp information to synchronize a set of related TS Logical Channels. It is also referred to as a TS_cell. Each TS Packet carries a PID value to associate it with a single TS Logical Channel.
TSパケット：TS Multiplex [ISO-MPEG]を介して送信されたデータの固定長18B単位。各TSパケットには、4Bヘッダーに加えて、適応フィールド、暗号化の詳細、タイムスタンプ情報を含むオプションのオーバーヘッドが搭載されており、関連するTS論理チャネルのセットを同期させます。TS_CELLとも呼ばれます。各TSパケットには、PID値があり、単一のTS論理チャネルに関連付けられます。
ULE: Unidirectional Lightweight Encapsulation (ULE) [IPDVB-ULE]. A scheme that encapsulates PDUs, into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel.
ule：単方向の軽量カプセル化（ule）[ipdvb-ule]。PDUをカプセル化するスキームは、単一のTS論理チャネルを使用して、一連のTSパケットで送信されるSNDUになります。
The following sections introduce the components of the MPEG-2 Transmission Network and relate these to a networking framework.
次のセクションでは、MPEG-2伝送ネットワークのコンポーネントを紹介し、これらをネットワークフレームワークに関連付けます。
There are many possible topologies for MPEG-2 Transmission Networks. A number of example scenarios are briefly described below, and the following text relates specific functions to this set of scenarios.
MPEG-2伝送ネットワークには、多くの可能なトポロジがあります。多くの例のシナリオを以下に簡単に説明し、次のテキストはこの一連のシナリオに特定の関数を関連付けます。
A) Broadcast TV and Radio Delivery The principal service in the Broadcast TV and Radio Delivery scenario is Digital TV and/or Radio and their associated data [MMUSIC-IMG, ETSI-IPDC]. Such networks typically contain two components: the contribution feed and the broadcast part. Contribution feeds provide communication from a typically small number of individual sites (usually at high quality) to the Hub of a broadcast network. The traffic carried on contribution feeds is typically encrypted, and is usually processed prior to being resent on the Broadcast part of the network. The Broadcast part uses a star topology centered on the Hub to reach a typically large number of down-stream Receivers. Although such networks may provide IP transmission, they do not necessarily provide access to the public Internet.
a）放送テレビとラジオ配信ブロードキャストテレビとラジオ配信シナリオの主要サービスは、デジタルテレビおよび/またはラジオとそれに関連するデータ[MMUSIC-IMG、ETSI-IPDC]です。このようなネットワークには、通常、貢献フィードとブロードキャストパーツの2つのコンポーネントが含まれています。貢献フィードは、通常、少数の個々のサイト（通常は高品質）から放送ネットワークのハブへの通信を提供します。貢献フィードでのトラフィックは通常暗号化され、通常はネットワークの放送部分にresする前に処理されます。ブロードキャストパートは、ハブを中心とした星トポロジを使用して、一般的に多数のダウンストリームレシーバーに到達します。このようなネットワークはIP送信を提供する可能性がありますが、必ずしもパブリックインターネットへのアクセスを提供するわけではありません。
B) Broadcast Networks used as an ISP Another scenario resembles that above, but includes the provision of IP services providing access to the public Internet. The IP traffic in this scenario is typically not related to the digital TV/Radio content, and the service may be operated by an independent operator such as unidirectional file delivery or bidirectional ISP access. The IP service must adhere to the full system specification used for the broadcast transmission, including allocation of PIDs and generation of appropriate MPEG-2 control information (e.g., DVB and ATSC SI tables).
b）ISPとして使用されるブロードキャストネットワークは、上記の別のシナリオに似ていますが、パブリックインターネットへのアクセスを提供するIPサービスの提供が含まれています。このシナリオのIPトラフィックは通常、デジタルTV/ラジオのコンテンツとは関係ありません。また、サービスは、単方向ファイル配信や双方向ISPアクセスなどの独立したオペレーターによって運用される場合があります。IPサービスは、PIDの割り当てや適切なMPEG-2制御情報の生成（DVBやATSC SIテーブルなど）の生成など、ブロードキャスト送信に使用される完全なシステム仕様に準拠する必要があります。
C) Unidirectional Star IP Scenario The Unidirectional Star IP Scenario utilizes a Hub station to provide a data network delivering a common bit stream to typically medium-sized groups of Receivers. MPEG-2 transmission technology provides the forward direction physical and link layers for this transmission; the return link (if required) is provided by other means. IP services typically form the main proportion of the transmission traffic. Such networks do not necessarily implement the MPEG-2 control plane, i.e., PSI/SI tables.
c）単方向スターIPシナリオ単方向スターIPシナリオは、ハブステーションを利用して、一般的に中規模のレシーバーグループに共通ビットストリームを提供するデータネットワークを提供します。MPEG-2トランスミッションテクノロジーは、この伝送の前方方向の物理レイヤーとリンク層を提供します。返品リンク（必要な場合）は、他の手段によって提供されます。通常、IPサービスは伝送トラフィックの主要な割合を形成します。このようなネットワークは、必ずしもMPEG-2コントロールプレーン、つまりPSI/SIテーブルを実装するわけではありません。
D) Datacast Overlay The Datacast Overlay scenario employs MPEG-2 physical and link layers to provide additional connectivity such as unidirectional multicast to supplement an existing IP-based Internet service. Examples of such a network includes IP Datacast to mobile wireless receivers [MMUSIC-IMG].
d）データキャストオーバーレイDataCast Overlayシナリオでは、MPEG-2の物理レイヤーとリンクレイヤーを使用して、既存のIPベースのインターネットサービスを補完する単方向マルチキャストなどの追加の接続を提供します。このようなネットワークの例には、モバイルワイヤレスレシーバー[MMUSIC-IMG]へのIPデータキャストが含まれます。
E) Point-to-Point Links Point-to-Point connectivity may be provided using a pair of transmit and receive interfaces supporting the MPEG-2 physical and link layers. Typically, the transmission from a sender is received by only one or a small number of Receivers. Examples include the use of transmit/receive DVB-S terminals to provide satellite links between ISPs utilising BGP routing.
e）ポイントツーポイントリンクは、MPEG-2の物理レイヤーとリンク層をサポートする送信および受信インターフェイスを使用して、ポイントツーポイント接続を提供できます。通常、送信者からのトランスミッションは、1つまたは少数の受信機のみが受信します。例には、BGPルーティングを使用しているISP間の衛星リンクを提供するために、送信/受信DVB-S端子の使用が含まれます。
F) Two-Way IP Networks Two-Way IP networks are typically satellite-based and star-based utilising a Hub station to deliver a common bit stream to medium-sized groups of receivers. A bidirectional service is provided over a common air-interface. The transmission technology in the forward direction at the physical and link layers is MPEG-2, which may also be used in the return direction. Such systems also usually include a control plane element to manage the (shared) return link capacity. A concrete example is the DVB-RCS system [ETSI-DVBRCS]. IP services typically form the main proportion of the transmission traffic.
f）双方向IPネットワーク双方向IPネットワークは、通常、衛星ベースとスターベースのハブステーションを使用して、中規模のレシーバーグループに共通のビットストリームを提供します。双方向サービスは、一般的な空気インターフェイスを介して提供されます。物理層とリンク層の前方向の伝送技術はMPEG-2であり、これも戻り方向に使用できます。このようなシステムには、通常、（共有）リンク容量を管理するコントロールプレーン要素も含まれます。具体的な例は、DVB-RCSシステム[ETSI-DVBRCS]です。通常、IPサービスは伝送トラフィックの主要な割合を形成します。
Scenarios A-D employ unidirectional MPEG-2 Transmission Networks. For satellite-based networks, these typically have a star topology, with a central Hub providing service to large numbers of down-stream Receivers. Terrestrial networks may employ several transmission Hubs, each serving a particular coverage cell with a community of Receivers.
シナリオA-Dは、一方向のMPEG-2伝送ネットワークを使用します。衛星ベースのネットワークの場合、これらには通常、スタートポロジがあり、中央のハブが多数のダウンストリームレシーバーにサービスを提供しています。地上ネットワークは、いくつかのトランスミッションハブを採用する場合があり、それぞれが受信機のコミュニティで特定のカバレッジセルを提供します。
From an IP viewpoint, the service is typically either unidirectional multicast, or a bidirectional service in which some complementary link technology (e.g., modem, Local Multipoint Distribution Service (LMDS), General Packet Radio Service (GPRS)) is used to provide the return path from Receivers to the Internet. In this case, routing could be provided using UniDirectional Link Routing (UDLR) [RFC3077].
IPの観点から、サービスは通常、単方向マルチキャストまたは補完的なリンクテクノロジー（モデム、ローカルマルチポイント配信サービス（LMDS）など、一般的なパケットラジオサービス（GPRS））を使用して、レシーバーからインターネットへのリターンパスを提供する双方向サービスです。この場合、単方向リンクルーティング（UDLR）[RFC3077]を使用してルーティングを提供できます。
Note that only Scenarios A-B actually carry MPEG-2 video and audio (intended for reception by digital Set Top Boxes (STBs)) as the primary traffic. The other scenarios are IP-based data networks and need not necessarily implement the MPEG-2 control plane.
シナリオA-Bのみが、実際にはMPEG-2ビデオとオーディオ（デジタルセットトップボックス（STB）による受信を目的としています）をプライマリトラフィックとして運ぶことに注意してください。他のシナリオはIPベースのデータネットワークであり、必ずしもMPEG-2コントロールプレーンを実装する必要はありません。
Scenarios E-F provide two-way connectivity using the MPEG-2 Transmission Network. Such networks provide direct support for bidirectional protocols above and below the IP layer.
シナリオE-Fは、MPEG-2トランスミッションネットワークを使用して双方向接続を提供します。このようなネットワークは、IPレイヤーの上および下の双方向プロトコルを直接サポートします。
The complete MPEG-2 transmission network may be managed by a transmission service operator. In such cases, the assignment of addresses and TS Logical Channels at Receivers are usually under the control of the service operator. Examples include a TV operator (Scenario A), or an ISP (Scenarios B-F). MPEG-2 transmission networks are also used for private networks. These typically involve a smaller number of Receivers and do not require the same level of centralized control. Examples include companies wishing to connect DVB-capable routers to form links within the Internet (Scenario B).
完全なMPEG-2トランスミッションネットワークは、トランスミッションサービスオペレーターによって管理される場合があります。そのような場合、受信機でのアドレスとTS論理チャネルの割り当ては通常、サービスオペレーターの管理下にあります。例には、テレビオペレーター（シナリオA）またはISP（シナリオB-F）が含まれます。MPEG-2トランスミッションネットワークは、プライベートネットワークにも使用されます。これらには通常、レシーバーが少なくなり、同じレベルの集中制御を必要としません。例には、DVB対応のルーターを接続してインターネット内にリンクを形成したい企業（シナリオB）が含まれます。
An MPEG-2 Transport Multiplex offers a number of parallel channels, which are known here as TS Logical Channels. Each TS Logical Channel is uniquely identified by the Packet ID (PID) value that is carried in the header of each MPEG-2 TS Packet. The PID value is a 13 bit field; thus, the number of available channels ranges from 0 to 8191 decimal or 0x1FFF in hexadecimal, some of which are reserved for transmission of SI tables. Non-reserved TS Logical Channels may be used to carry audio [ISO-AUD], video [ISO-VID], IP packets [ISO-DSMCC, ETSI-DAT, ATSC-DAT], or other data [ISO-DSMCC, ETSI-DAT, ATSC-DAT]. The value 8191 decimal (0x1FFF) indicates a null packet that is used to maintain the physical bearer bit rate when there are no other MPEG-2 TS packets to be sent.
MPEG-2トランスポートマルチプレックスは、ここでTS論理チャネルとして知られている多くの並列チャネルを提供します。各TS論理チャネルは、各MPEG-2 TSパケットのヘッダーに掲載されるパケットID（PID）値によって一意に識別されます。PID値は13ビットフィールドです。したがって、利用可能なチャネルの数は、16進数で0〜8191小数または0x1FFFの範囲であり、その一部はSIテーブルの送信用に予約されています。非予定のTS論理チャネルは、オーディオ[ISO-AUD]、ビデオ[ISO-VID]、IPパケット[ISO-DSMCC、ETSI-DAT、ATSC-DAT]、またはその他のデータ[ISO-DSMCC、ETSI-DAT、ATSC-DAT]を運ぶために使用できます。値8191 10進数（0x1FFF）は、送信される他のMPEG-2 TSパケットがない場合に物理ベアラービットレートを維持するために使用されるヌルパケットを示します。
TS-LC-A-1 /---\--------------------/---\
\ / \ / \
\ | | | |
TS-LC-A-2 ----------- | | -------------
-------------------- | | -------------
| | | |
/-------- / | -------------
/ \----/-------------------\----/
TS-LC-A-3/ MPEG-2 TS MUX A
/
TS-LC /
------------X
\ TS-LC-B-3 /---\------------------------/---\
\ / \ / \
\ | | | |
TS-LC-B-2 \----------- | | ---------
-------------------- | | ---------
| | | |
/-------- / | ---------
/ \----/-----------------------\----/
/ MPEG-2 TS MUX B
TS-LC-B-1
Figure 2: Example showing MPEG-2 TS Logical Channels carried Over 2 MPEG-2 TS Multiplexes.
図2：MPEG-2 TS論理チャネルが2つ以上のMPEG-2 TSマルチプレックスを搭載していることを示す例。
TS Logical Channels are independently numbered on each MPEG-2 TS Multiplex (MUX). In most cases, the data sent over the TS Logical Channels will differ for different multiplexes. Figure 2 shows a set of TS Logical Channels sent using two MPEG-2 TS Multiplexes (A and B).
TS論理チャネルは、各MPEG-2 TSマルチプレックス（MUX）で個別に番号が付けられています。ほとんどの場合、TS論理チャネルを介して送信されたデータは、異なるマルチプレックスで異なります。図2は、2つのMPEG-2 TSマルチプレックス（AおよびB）を使用して送信されたTS論理チャネルのセットを示しています。
There are cases where the same data may be distributed over two or more multiplexes (e.g., some SI tables; multicast content that needs to be received by Receivers tuned to either MPEG-2 TS; unicast data where the Receiver may be in either/both of two potentially overlapping MPEG-2 transmission cells). In figure 2, each multiplex carries 3 MPEG-2 TS Logical Channels. These TS Logical Channels may differ (TS-LC-A-1, TS-LC-A-2, TS-LC-B-2, TS-LC-B-1), or may be common to both MPEG-2 TS Multiplexes (i.e., TS-LC-A-3 and TS-LC-B-3 carry identical content).
同じデータが2つ以上のマルチプレックス（たとえば、一部のSIテーブル、MPEG-2 TSのいずれかに調整された受信機が受信する必要があるマルチキャストコンテンツ、レシーバーが2つの潜在的に重複するMPEG-2透過細胞のいずれか/両方にある可能性があるユニキャストデータ）に分布する場合があります。図2では、各マルチプレックスには3つのMPEG-2 TS論理チャネルが含まれています。これらの論理チャネルは異なる場合があります（TS-LC-A-1、TS-LC-A-2、TS-LC-B-2、TS-LC-B-1）、またはMPEG-2 TSマルチプレックス（つまり、TS-LC-A-3とTS-LC-B-3の両方に共通する場合があります。
As can been seen, there are similarities between the way PIDs are used and the operation of virtual channels in ATM. However, unlike ATM, a PID defines a unidirectional broadcast channel and not a point-to-point link. Contrary to ATM, there is, as yet, no specified standard interface for MPEG-2 connection setup, or for signaling mappings of IP flows to PIDs, or to set the Quality of Service, QoS, assigned to a TS Logical Channel.
ご覧のとおり、PIDの使用方法とATMでの仮想チャネルの動作との間には類似点があります。ただし、ATMとは異なり、PIDはポイントツーポイントリンクではなく、単方向ブロードキャストチャネルを定義します。ATMとは反対に、MPEG-2接続セットアップ、またはPIDへのIPフローのシグナリングマッピング、またはTS論理チャネルに割り当てられたサービス品質QOSを設定するための指定された標準インターフェイスはまだありません。
In a simple example, one or more TS Logical Channels are processed by an MPEG-2 multiplexor, resulting in a TS Multiplex. The TS Multiplex is forwarded over a physical bearer towards one or more Receivers (Figure 3).
簡単な例では、1つ以上のTS論理チャネルがMPEG-2マルチプレクサーによって処理され、TSマルチプレックスが生じます。TSマルチプレックスは、物理的な担い手を介して1つ以上のレシーバーに転送されます（図3）。
In a more complex example, the same TS may be fed to multiple MPEG-2 multiplexors and these may, in turn, feed other MPEG-2 multiplexors (remultiplexing). Remultiplexing may occur in several places (and is common in Scenarios A and B of Section 3.1). One example is a satellite that provides on-board processing of the TS packets, multiplexing the TS Logical Channels received from one or more uplink physical bearers (TS Multiplex) to one (or more in the case of broadcast/multicast) down-link physical bearer (TS Multiplex). As part of the remultiplexing process, a remultiplexor may renumber the PID values associated with one or more TS Logical Channels to prevent clashes between input TS Logical Channels with the same PID carried on different input multiplexes. It may also modify and/or insert new SI data into the control plane.
より複雑な例では、同じTSが複数のMPEG-2マルチプレクサに供給される場合があり、これらは他のMPEG-2マルチプレクサ（再退屈）を供給する場合があります。再退屈はいくつかの場所で発生する可能性があります（セクション3.1のシナリオAおよびBで一般的です）。1つの例は、TSパケットのオンボード処理を提供する衛星です。1つまたは複数のアップリンク物理ベアラー（TSマルチプレックス）から1つ（またはブロードキャスト/マルチキャストの場合）のダウンリンク物理ベアラー（TSマルチプレックス）に受け取ったTS論理チャネルを多重化します。再退屈プロセスの一環として、再gultiplexorは、1つ以上のTS論理チャネルに関連付けられたPID値を変更して、異なる入力マルチプレックスで運ばれる同じPIDで入力TS論理チャネル間の衝突を防ぐことができます。また、新しいSIデータを制御プレーンに変更および/または挿入することもできます。
In all cases, the final result is a "TS Multiplex" that is transmitted over the physical bearer towards the Receiver.
すべての場合において、最終結果は、物理ベアラーを介して受信機に向かって送信される「TSマルチプレックス」です。
+------------+ +------------+
| IP | | IP |
| End Host | | End Host |
+-----+------+ +------------+
| ^
+------------>+---------------+ |
+ IP | |
+-------------+ Encapsulator | |
SI-Data | +------+--------+ |
+-------+-------+ |MPEG-2 TS Logical Channel |
| MPEG-2 | | |
| SI Tables | | |
+-------+-------+ ->+------+--------+ |
| -->| MPEG-2 | . . .
+------------>+ Multiplexor | |
MPEG-2 TS +------+--------+ |
Logical Channel |MPEG-2 TS Mux |
| |
Other ->+------+--------+ |
MPEG-2 -->+ MPEG-2 | |
TS --->+ Multiplexor | |
---->+------+--------+ |
|MPEG-2 TS Mux |
| |
+------+--------+ +------+-----+
|Physical Layer | | MPEG-2 |
|Modulator +---------->+ Receiver |
+---------------+ MPEG-2 +------------+
TS Mux
Figure 3: An example configuration for a unidirectional Service for IP transport over MPEG-2
図3：MPEG-2を介したIP輸送の単方向サービスの例の構成
Packet data for transmission over an MPEG-2 Transport Multiplex is passed to an Encapsulator, sometimes known as a Gateway. This receives Protocol Data Units, PDUs, such as Ethernet frames or IP packets, and formats each into a Sub-Network Data Unit, SNDU, by adding an encapsulation header and trailer (see Section 4). The SNDUs are subsequently fragmented into a series of TS Packets.
MPEG-2トランスポートマルチプレックスを介した送信用のパケットデータは、ゲートウェイとして知られる場合もあるエンコーサに渡されます。これにより、イーサネットフレームやIPパケットなどのプロトコルデータユニット、PDUを受信し、カプセル化ヘッダーとトレーラーを追加することにより、それぞれサブネットワークデータユニットSNDUにフォーマットします（セクション4を参照）。その後、SNDUは一連のTSパケットに断片化されます。
To receive IP packets over an MPEG-2 TS Multiplex, a Receiver needs to identify the specific TS Multiplex (physical link) and also the TS Logical Channel (the PID value of a logical link). It is common for a number of MPEG-2 TS Logical Channels to carry SNDUs; therefore, a Receiver must filter (accept) IP packets sent with a number of PID values, and must independently reassemble each SNDU.
MPEG-2 TSマルチプレックスでIPパケットを受信するには、受信者は特定のTSマルチプレックス（物理リンク）とTS論理チャネル（論理リンクのPID値）を識別する必要があります。多くのMPEG-2 TS論理チャネルがSNDUを運ぶことが一般的です。したがって、受信者は、多数のPID値で送信されたIPパケットをフィルタリング（受け入れる）し、各SNDUを個別に再組み立てする必要があります。
A Receiver that simultaneously receives from several TS Logical Channels must filter other unwanted TS Logical Channels by employing, for example, specific hardware support. Packets for one IP flow (i.e., a specific combination of IP source and destination addresses) must be sent using the same PID. It should not be assumed that all IP packets are carried on a single PID, as in some cable modem implementations, and multiple PIDs must be allowed in the architecture. Many current hardware filters limit the maximum number of active PIDs (e.g., 32), although if needed, future systems may reasonably be expected to support more.
いくつかのTS論理チャネルから同時に受信するレシーバーは、特定のハードウェアサポートを使用することにより、他の不要なTS論理チャネルをフィルタリングする必要があります。同じPIDを使用して、1つのIPフロー（つまり、IPソースアドレスと宛先アドレスの特定の組み合わせ）のパケットを送信する必要があります。一部のケーブルモデムの実装のように、すべてのIPパケットが単一のPIDで運ばれ、アーキテクチャでは複数のPIDを許可する必要があると想定してはなりません。現在の現在のハードウェアフィルターの多くは、アクティブなPIDの最大数を制限します（例：32）。ただし、必要に応じて、将来のシステムがより多くをサポートすることが合理的に期待される場合があります。
In some cases, Receivers may need to select TS Logical Channels from a number of simultaneously active TS Multiplexes. To do this, they need multiple physical receive interfaces (e.g., radio frequency (RF) front-ends and demodulators). Some applications also envisage the concurrent reception of IP Packets over other media that may not necessarily use MPEG-2 transmission.
場合によっては、受信者は、多くの同時にアクティブなTSマルチプレックスからTS論理チャネルを選択する必要がある場合があります。これを行うには、複数の物理的な受信インターフェイス（たとえば、無線周波数（RF）フロントエンドと復調剤）が必要です。一部のアプリケーションでは、MPEG-2伝送を必ずしも使用しない場合がある他のメディアに対するIPパケットの同時受信も想定しています。
Bidirectional (duplex) transmission can be provided using an MPEG-2 Transmission Network by using one of a number of alternate return channel schemes [ETSI-RC]. Duplex IP paths may also be supported using non-MPEG-2 return links (e.g., in Scenarios B-D of section 3.1). One example of such an application is that of UniDirectional Link Routing, UDLR [RFC3077].
多数の代替リターンチャネルスキーム[ETSI-RC]のいずれかを使用して、MPEG-2トランスミッションネットワークを使用して、双方向（デュプレックス）伝送を提供できます。デュプレックスIPパスは、非MPEG-2リターンリンクを使用してサポートされる場合があります（たとえば、セクション3.1のシナリオB-D）。このようなアプリケーションの1つの例は、単方向リンクルーティング、UDLR [RFC3077]の例です。
The network layer protocols to be supported by this architecture include:
このアーキテクチャでサポートされるネットワークレイヤープロトコルは次のとおりです。
(i) IPv4 Unicast packets, destined for a single end host
(i) 単一のエンドホスト用に運命づけられたIPv4ユニキャストパケット
(ii) IPv4 Broadcast packets, sent to all end systems in an IP network
（ii）IPv4ネットワークのすべてのエンドシステムに送信されるIPv4ブロードキャストパケット
(iii) IPv4 Multicast packets
（iii）IPv4マルチキャストパケット
(iv) IPv6 Unicast packets, destined for a single end host
（iv）単一のエンドホスト用に運命づけられたIPv6ユニキャストパケット
(v) IPv6 Multicast packets
(v) IPv6マルチキャストパケット
(vi) Packets with compressed IPv4 / IPv6 packet headers (e.g., [RFC2507, RFC3095])
（vi）圧縮されたIPv4 / IPv6パケットヘッダーを備えたパケット（例：[RFC2507、RFC3095]））
(vii) Bridged Ethernet frames
（vii）ブリッジ付きイーサネットフレーム
(viii) Other network protocol packets (MPLS, potential new protocols) The architecture will provide:
（viii）その他のネットワークプロトコルパケット（MPLS、潜在的な新しいプロトコル）アーキテクチャが提供します。
(i) Guidance on which MPEG-2 features are pre-requisites for the IP service, and identification of any optional fields that impact performance/correct operation.
(i) MPEG-2機能がIPサービスの前提条件であるガイダンス、およびパフォーマンス/正しい操作に影響を与えるオプションのフィールドの識別。
(ii) Standards to provide an efficient and flexible encapsulation scheme that may be easily implemented in an Encapsulator or Receiver. The payload encapsulation requires a type field for the SNDU to indicate the type of packet and a mechanism to signal which encapsulation is used on a certain PID.
（ii）エンコートまたはレシーバーで簡単に実装できる効率的で柔軟なカプセル化スキームを提供する標準。ペイロードカプセル化には、SNDUがパケットのタイプを示すためのタイプフィールドと、特定のPIDで使用されるカプセル化を通知するメカニズムが必要です。
(iii) Standards to associate a particular IP address with a Network Point of Attachment (NPA) that could or may not be a MAC Address. This process resembles the IPv4 Address Resolution Protocol, ARP, or IPv6 Neighbor Discovery, ND, protocol [IPDVB-AR]. In addition, the standard will be compatible with IPv6 autoconfiguration.
（iii）特定のIPアドレスを、MACアドレスである可能性がある場合とそうでない場合があるネットワークポイント（NPA）に関連付けるための標準。このプロセスは、IPv4アドレス解像度プロトコル、ARP、またはIPv6 Neighbor Discovery、ND、Protocol [IPDVB-AR]に似ています。さらに、標準はIPv6 Autoconfigurationと互換性があります。
(iv) Standards to associate an MPEG-2 TS interface with one or more specific TS Logical Channels (PID, TS Multiplex). Bindings are required for both unicast transmission, and multicast reception. In the case of IPv4, this must also support network broadcast. To make the schemes robust to loss and state changes within the MPEG-2 transmission network, a soft-state approach may prove desirable.
（iv）MPEG-2 TSインターフェイスを1つ以上の特定のTS論理チャネル（PID、TSマルチプレックス）に関連付けるための標準。ユニキャストトランスミッションとマルチキャストレセプションの両方にバインディングが必要です。IPv4の場合、これはネットワークブロードキャストもサポートする必要があります。MPEG-2トランスミッションネットワーク内の損失および状態の変更に対してスキームを堅牢にするためには、ソフトステートアプローチが望ましいことが証明される場合があります。
(v) Standards to associate the capabilities of an MPEG-2 TS Logical Channel with IP flows. This includes mapping of QoS functions, such as IP QoS/DSCP and RSVP, to underlying MPEG-2 TS QoS, multi-homing and mobility. This capability could be associated by the AR standard proposed above.
(v) MPEG-2 TS論理チャネルの機能をIPフローに関連付けるための標準。これには、IP QOS/DSCPやRSVPなどのQOS関数の基礎となるMPEG-2 TS QOS、マルチホミング、モビリティへのマッピングが含まれます。この機能は、上記のAR標準で関連付けられる可能性があります。
(vi) Guidance on Security for IP transmission over MPEG-2. The framework must permit use of IPsec and clearly identify any security issues concerning the specified protocols. The security issues need to consider two cases: unidirectional transfer (in which communication is only from the sending IP end host to the receiving IP end host) and bidirectional transfer. Consideration should also be given to security of the TS Multiplex: the need for closed user groups and the use of MPEG-2 TS encryption.
（vi）MPEG-2を介したIP送信のセキュリティに関するガイダンス。このフレームワークは、IPSECの使用を許可し、指定されたプロトコルに関するセキュリティの問題を明確に特定する必要があります。セキュリティの問題は、2つのケースを考慮する必要があります。単方向転送（通信は、送信IPエンドホストから受信IPエンドホストへのみ）と双方向転送です。また、TSマルチプレックスのセキュリティを考慮する必要があります。閉じたユーザーグループの必要性とMPEG-2 TS暗号化の使用です。
(vii) Management of the IP transmission, including standardized SNMP MIBs and error reporting procedures. The need for and scope of this is to be determined.
（vii）標準化されたSNMP MIBSおよびエラー報告手順を含むIP伝送の管理。これの必要性と範囲は決定されることです。
The specified architecture and techniques should be suited to a range of systems employing the MPEG-2 TS, and may also suit other (sub)networks offering similar transfer capabilities.
指定されたアーキテクチャと手法は、MPEG-2 TSを使用するさまざまなシステムに適している必要があり、同様の転送機能を提供する他の（サブ）ネットワークにも適している場合があります。
The following section, 4, describes encapsulation issues. Sections 5 and 6 describe address resolution issues for unicast and multicast, respectively.
次のセクション4では、カプセル化の問題について説明します。セクション5と6は、それぞれユニキャストとマルチキャストの住所解像度の問題について説明します。
This section identifies requirements and provides examples of mechanisms that may be used to perform the encapsulation of IPv4/v6 unicast and multicast packets over MPEG-2 Transmission Networks.
このセクションでは、要件を特定し、MPEG-2伝送ネットワークを介したIPv4/V6ユニキャストおよびマルチキャストパケットのカプセル化を実行するために使用できるメカニズムの例を提供します。
A network device, known as an Encapsulator receives PDUs (e.g., IP Packets or Ethernet frames) and formats these into Subnetwork Data Units, SNDUs. An encapsulation (or convergence) protocol transports each SNDU over the MPEG-2 TS service and provides the appropriate mechanisms to deliver the encapsulated PDU to the Receiver IP interface.
カプセレータとして知られるネットワークデバイスは、PDU（IPパケットやイーサネットフレームなど）を受信し、これらをサブネットワークデータユニットのSNDUにフォーマットします。カプセル化（または収束）プロトコルは、各SNDUをMPEG-2 TSサービス上で輸送し、カプセル化されたPDUを受信機IPインターフェイスに供給するための適切なメカニズムを提供します。
In forming an SNDU, the encapsulation protocol typically adds header fields that carry protocol control information, such as the length of SNDU, Receiver address, multiplexing information, payload type, sequence numbers, etc. The SNDU payload is typically followed by a trailer, which carries an Integrity Check (e.g., Cyclic Redundancy Check, CRC). Some protocols also add additional control information and/or padding to or after the trailer (figure 4).
SNDUを形成する際、カプセル化プロトコルは通常、SNDU、レシーバーアドレス、多重化情報、ペイロードタイプ、シーケンス番号などのプロトコル制御情報を運ぶヘッダーフィールドを追加します。SNDUペイロードには、通常、完全性チェック、CRC、CRC、CRC、CRC）を伴うトレーラーが続きます。一部のプロトコルは、トレーラーに追加の制御情報やパディングを追加します（図4）。
+--------+-------------------------+-----------------+
| Header | PDU | Integrity Check |
+--------+-------------------------+-----------------+
<--------------------- SNDU ------------------------->
Figure 4: Encapsulation of a subnetwork PDU (e.g., IPv4 or IPv6 packet) to form an MPEG-2 Payload Unit.
図4：MPEG-2ペイロードユニットを形成するために、サブネットワークPDU（IPv4またはIPv6パケットなど）のカプセル化。
Examples of existing encapsulation/convergence protocols include ATM AAL5 [ITU-AAL5] and MPEG-2 MPE [ETSI-DAT].
既存のカプセル化/収束プロトコルの例には、ATM AAL5 [ITU-AAL5]およびMPEG-2 MPE [ETSI-DAT]が含まれます。
When required, an SNDU may be fragmented across a number of TS Packets (figure 5).
必要に応じて、SNDUは多くのTSパケットで断片化される場合があります（図5）。
+-----------------------------------------+
|Encap Header|SubNetwork Data Unit (SNDU) |
+-----------------------------------------+
/ / \ \
/ / \ \
/ / \ \
+------+----------+ +------+----------+ +------+----------+
|MPEG-2| MPEG-2 |..|MPEG-2| MPEG-2 |...|MPEG-2| MPEG-2 |
|Header| Payload | |Header| Payload | |Header| Payload |
+------+----------+ +------+----------+ +------+----------+
Figure 5: Encapsulation of a PDU (e.g., IP packet) into a Series of MPEG-2 TS Packets. Each TS Packet carries a header with a common Packet ID (PID) value denoting the MPEG-2 TS Logical Channel.
図5：一連のMPEG-2 TSパケットへのPDU（例：IPパケット）のカプセル化。各TSパケットには、MPEG-2 TS論理チャネルを示す共通のパケットID（PID）値を持つヘッダーが搭載されています。
The DVB family of standards currently defines a mechanism for transporting an IP packet, or Ethernet frame using the Multi-Protocol Encapsulation (MPE) [ETSI-DAT]. An equivalent scheme is also supported in ATSC [ATSC-DAT, ATSC-DATG]. It allows transmission of IP packets or (by using LLC) Ethernet frames by encapsulation within a Table Section (with the format used by the control plane associated with the MPEG-2 transmission). The MPE specification includes a set of optional header components and requires decoding of the control headers. This processing is suboptimal for Internet traffic, since it incurs significant receiver processing overhead and some extra link overhead [CLC99].
DVB標準ファミリーは現在、マルチプロトコルカプセル化（MPE）[ETSI-DAT]を使用して、IPパケットまたはイーサネットフレームを輸送するメカニズムを定義しています。同等のスキームは、ATSC [ATSC-DAT、ATSC-DATG]でもサポートされています。これにより、テーブルセクション内のカプセル化により（MPEG-2伝送に関連付けられたコントロールプレーンで使用される形式を使用）、IPパケットまたは（LLCを使用することにより）イーサネットフレームを送信できます。MPE仕様には、一連のオプションのヘッダーコンポーネントが含まれており、コントロールヘッダーのデコードが必要です。この処理は、インターネットトラフィックの最適ではありません。これは、重要なレシーバー処理オーバーヘッドといくつかの追加リンクオーバーヘッド[CLC99]を負担するためです。
The existing standards carry heritage from legacy implementations. These have reflected the limitations of technology at the time of their deployment (e.g., design decisions driven by audio/video considerations rather than IP networking requirements). IPv6, MPLS, and other network-layer protocols are not natively supported. Together, these justify the development of a new encapsulation that will be truly IP-centric. Carrying IP packets over a TS Logical Channel involves several convergence protocol functions. This section briefly describes these functions and highlights the requirements for a new encapsulation.
既存の標準は、レガシーの実装から遺産を抱えています。これらは、展開時のテクノロジーの制限を反映しています（たとえば、IPネットワーキング要件ではなく、オーディオ/ビデオの考慮事項によって推進される設計上の決定）。IPv6、MPLS、およびその他のネットワーク層プロトコルはネイティブにサポートされていません。一緒に、これらは本当にIP中心の新しいカプセル化の開発を正当化します。TS論理チャネルにIPパケットを運ぶには、いくつかの収束プロトコル関数が含まれます。このセクションでは、これらの機能について簡単に説明し、新しいカプセル化の要件を強調します。
MPEG-2 indicates the start of a Payload Unit (PU) in a new TS Packet with a "payload_unit_start_indicator" (PUSI) [ISO-MPEG] carried in the 4B TS Packet header. The PUSI is a 1 bit flag that has normative meaning [ISO-MPEG] for TS Packets that carry PES Packets or PSI/SI data.
MPEG-2は、4B TSパケットヘッダーで運ばれた「payload_unit_start_indicator」（pusi）[iso-mpeg]を備えた新しいTSパケットのペイロードユニット（PU）の開始を示します。PUSIは、PESパケットまたはPSI/SIデータを運ぶTSパケットの規範的な意味[ISO-MPEG]を持つ1ビットフラグです。
When the payload of a TS Packet contains PES data, a PUSI value of '1' indicates the TS Packet payload starts with the first byte of a PES Packet. A value of '0' indicates that no PES Packet starts in the TS Packet. If the PUSI is set to '1', then one, and only one, PES Packet starts in the TS Packet.
TSパケットのペイロードにPESデータが含まれている場合、「1」のPUSI値は、PESパケットの最初のバイトからTSパケットペイロードの開始を示します。「0」の値は、TSパケットでPESパケットが起動しないことを示します。pusiが「1」に設定されている場合、1つだけで1つだけ、PESパケットはTSパケットで開始されます。
When the payload of the TS Packet contains PSI data, a PUSI value of '1' indicates the first byte of the TS Packet payload carries a Payload Pointer (PP) that indicates the position of the first byte of the Payload Unit (Table Section) being carried; if the TS Packet does not carry the first byte of a Table Section, the PUSI is set to '0', indicating that no Payload Pointer is present.
TSパケットのペイロードにPSIデータが含まれる場合、「1」のPUSI値は、TSパケットペイロードの最初のバイトがペイロードポインター（PP）を運ぶことを示します。TSパケットがテーブルセクションの最初のバイトを運ばない場合、PUSIは「0」に設定されており、ペイロードポインターが存在しないことを示します。
Using this PUSI bit, the start of the first Payload Unit in a TS Packet is exactly known by the Receiver, unless that TS Packet has been corrupted or lost in the transmission. In which case, the payload is discarded until the next TS Packet is received with a PUSI value of '1'.
このPusiビットを使用して、TSパケットの最初のペイロードユニットの開始は、TSパケットが送信で破損または失われていない限り、受信機によって正確に知られています。その場合、ペイロードは、次のTSパケットが「1」のPUSI値で受信されるまで破棄されます。
The encapsulation should allow packing of more than one SNDU into the same TS Packet and should not limit the number of SNDUs that can be sent in a TS Packet. In addition, it should allow an IP Encapsulator to insert padding when there is an incomplete TS Packet payload. A mechanism needs to be identified to differentiate this padding from the case where another encapsulated SNDU follows.
カプセル化により、複数のSNDUを同じTSパケットに梱包することができ、TSパケットで送信できるSNDUの数を制限しないでください。さらに、不完全なTSパケットペイロードがある場合、IPエンカプセーターがパディングを挿入できるようにする必要があります。このパディングを別のカプセル化されたSNDUが続く場合と区別するために、メカニズムを特定する必要があります。
A combination of the PUSI and a Length Indicator (see below) allows an efficient MPEG-2 convergence protocol to receive accurate delineation of packed SNDUs. The MPEG-2 standard [ISO-MPEG] does not specify how private data should use the PUSI bit.
PUSIと長さのインジケーターの組み合わせ（以下を参照）により、効率的なMPEG-2収束プロトコルがパックされたSNDUの正確な描写を受信することができます。MPEG-2標準[ISO-MPEG]は、プライベートデータがPUSIビットを使用する方法を指定していません。
Most services using MPEG-2 include a length field in the Payload Unit header to allow the Receiver to identify the end of a Payload Unit (e.g., PES Packet, Section, or an SNDU).
MPEG-2を使用したほとんどのサービスには、ペイロードユニットヘッダーに長さフィールドが含まれており、受信機がペイロードユニット（PESパケット、セクション、またはSNDUなど）の端を識別できるようにします。
When parts of more than two Payload Units are carried in the same TS Packet, only the start of the first is indicated by the Payload Pointer. Placement of a Length Indicator in the encapsulation header allows a Receiver to determine the number of bytes until the start of the next encapsulated SNDU. This placement also provides the opportunity for the Receiver to pre-allocate an appropriate-sized memory buffer to receive the reassembled SNDU.
3つ以上のペイロードユニットの一部が同じTSパケットで運ばれる場合、最初のパケットの開始のみがペイロードポインターによって示されます。カプセル化ヘッダーに長さインジケーターを配置すると、レシーバーは次のカプセル化されたSNDUの開始までバイト数を決定できます。また、この配置は、受信者が適切なサイズのメモリバッファーを事前に割り当てて再組み立てされたSNDUを受信する機会を提供します。
A Length Indicator is required, and should be carried in the encapsulation header. This should support SNDUs of at least the MTU size offered by Ethernet (currently 1500 bytes). Although the IPv4 and IPv6 packet format permits an IP packet of size up to 64 KB, such packets are seldom seen on the current Internet. Since high speed links are often limited by the packet forwarding rate of routers, there has been a tendency for Internet core routers to support MTU values larger than 1500 bytes. A value of 16 KB is not uncommon in the core of the current Internet. This would seem a suitable maximum size for an MPEG-2 transmission network.
長さのインジケータが必要であり、カプセル化ヘッダーに携帯する必要があります。これは、少なくともイーサネット（現在1500バイト）で提供されるMTUサイズのSNDUをサポートするはずです。IPv4およびIPv6パケット形式では、最大64 kbのサイズのIPパケットが許可されていますが、このようなパケットは現在のインターネットではめったに見られません。多くの場合、高速リンクはルーターのパケット転送速度によって制限されるため、インターネットコアルーターが1500バイトを超えるMTU値をサポートする傾向がありました。16 kbの値は、現在のインターネットの中核では珍しくありません。これは、MPEG-2トランスミッションネットワークに適した最大サイズのように思えます。
Any IETF-defined encapsulation protocol should identify the payload type being transported (e.g., to differentiate IPv4, IPv6, etc). Most protocols use a type field to identify a specific process at the next higher layer that is the originator or the recipient of the payload (SNDU). This method is used by IPv4, IPv6, and also by the original Ethernet protocol (DIX). OSI uses the concept of a 'Selector' for this, (e.g., in the IEEE 802/ISO 8802 standards for CSMA/CD [LLC]; although in this case, a SNAP (subnetwork access protocol) header is also required for IP packets.
IETF定義のカプセル化プロトコルは、輸送されているペイロードタイプを識別する必要があります（たとえば、IPv4、IPv6などを区別するため）。ほとんどのプロトコルは、タイプフィールドを使用して、ペイロードのオリジネーターまたは受信者（SNDU）である次の高層で特定のプロセスを識別します。この方法は、IPv4、IPv6、および元のイーサネットプロトコル（DIX）によっても使用されます。OSIはこれに「セレクター」の概念を使用します（たとえば、CSMA/CD [LLC]のIEEE 802/ISO 8802標準では、この場合、IPパケットにはSNAP（サブネットワークアクセスプロトコル）ヘッダーも必要です。
A Next Level Protocol Type field is also required if compression (e.g., Robust Header Compression [RFC3095]) is supported. No compression method has currently been defined that is directly applicable to this architecture, however the ROHC framework defines a number of header compression techniques that may yield considerable improvement in throughput on links that have a limited capacity. Since many MPEG-2 Transmission Networks are wireless, the ROHC framework will be directly applicable for many applications. The benefit of ROHC is greatest for smaller SNDUs but does imply the need for additional processing at the Receiver to expand the received compressed packets. The selected type field should contain sufficient code points to support this technique.
圧縮（たとえば、堅牢なヘッダー圧縮[RFC3095]）がサポートされている場合、次のレベルのプロトコルタイプフィールドも必要です。現在、このアーキテクチャに直接適用できる圧縮方法は定義されていませんが、ROHCフレームワークは、容量が限られているリンクのスループットにかなりの改善をもたらす可能性のある多くのヘッダー圧縮技術を定義しています。多くのMPEG-2トランスミッションネットワークはワイヤレスであるため、ROHCフレームワークは多くのアプリケーションに直接適用されます。ROHCの利点は、より小さなSNDUで最も優れていますが、受信した圧縮パケットを拡張するために受信機で追加の処理が必要であることを意味します。選択したタイプフィールドには、この手法をサポートするのに十分なコードポイントを含める必要があります。
It is thus a requirement to include a Next Level Protocol Type field in the encapsulation header. Such a field should specify values for at least IPv4, IPv6, and must allow for other values (e.g., MAC-level bridging).
したがって、カプセル化ヘッダーに次のレベルのプロトコルタイプフィールドを含める必要があります。このようなフィールドは、少なくともIPv4、IPv6の値を指定し、他の値（たとえば、Macレベルのブリッジング）を可能にする必要があります。
In MPEG-2, the PID carried in the TS Packet header is used to identify individual services with the help of SI tables. This was primarily intended as a unidirectional (simplex) broadcast system. A TS Packet stream carries either tables or one PES Packet stream (i.e., compressed video or audio). Individual Receivers are not addressable at this level.
MPEG-2では、TSパケットヘッダーに携帯されているPIDを使用して、SIテーブルの助けを借りて個々のサービスを識別します。これは主に単方向（シンプレックス）ブロードキャストシステムとして意図されていました。TSパケットストリームには、テーブルまたは1つのPESパケットストリーム（つまり、圧縮ビデオまたはオーディオ）が含まれます。このレベルでは、個々のレシーバーはアドレス指定できません。
IPv4 and IPv6 allocate addresses to end hosts and intermediate systems (routers). Each system (or interface) is identified by a globally assigned address. ISO uses the concept of a hierarchically structured Network Service Access Point (NSAP) address to identify an end host user process in an Internet environment.
IPv4およびIPv6は、アドレスを割り当てて、ホストと中間システム（ルーター）を終了させます。各システム（またはインターフェイス）は、グローバルに割り当てられたアドレスによって識別されます。ISOは、階層的に構造化されたネットワークサービスアクセスポイント（NSAP）アドレスの概念を使用して、インターネット環境でエンドホストユーザープロセスを識別します。
Within a local network, a completely different set of addresses for the Network Point of Attachment (NPA) is used; frequently these NPA addresses are referred to as Medium Access Control, MAC-level addresses. In the Internet they are also called hardware addresses. Whereas network layer addresses are used for routing, NPA addresses are primarily used for Receiver identification.
ローカルネットワーク内では、ネットワークポイントの添付ファイル（NPA）の完全に異なるアドレスのセットが使用されます。多くの場合、これらのNPAアドレスは、Mediual Access Control、Macレベルのアドレスと呼ばれます。インターネットでは、ハードウェアアドレスとも呼ばれます。ネットワークレイヤーアドレスはルーティングに使用されますが、NPAアドレスは主に受信機の識別に使用されます。
Receivers may use the NPA of a received SNDU to reject unwanted unicast packets within the (software) interface driver at the Receiver, but must also perform forwarding checks based on the IP address. IP multicast and broadcast may also filter using the NPA, but Receivers must also filter unwanted packets at the network layer based on source and destination IP addresses. This does not imply that each IP address must map to a unique NPA (more than one IP address may map to the same NPA). If a separate NPA address is not required, the IP address is sufficient for both functions.
受信者は、受信したSNDUのNPAを使用して、レシーバーの（ソフトウェア）インターフェイスドライバー内の不要なユニキャストパケットを拒否することもできますが、IPアドレスに基づいて転送チェックを実行する必要があります。IPマルチキャストとブロードキャストもNPAを使用してフィルタリングする場合がありますが、受信機はソースおよび宛先IPアドレスに基づいてネットワークレイヤーで不要なパケットをフィルタリングする必要があります。これは、各IPアドレスが一意のNPAにマッピングする必要があることを意味するものではありません（複数のIPアドレスが同じNPAにマッピングできる場合）。別のNPAアドレスが不要な場合、両方の機能にIPアドレスで十分です。
If it is required to address an individual Receiver in an MPEG-2 transport system, this can be achieved either at the network level (IP address) or via a hardware-level NPA address (MAC-address). If both addresses are used, they must be mapped in either a static or a dynamic way (e.g., by an address resolution process). A similar requirement may also exist to identify the PID and TS multiplex on which services are carried.
MPEG-2トランスポートシステムで個々のレシーバーに対処する必要がある場合、これはネットワークレベル（IPアドレス）またはハードウェアレベルのNPAアドレス（Mac-Address）で達成できます。両方のアドレスを使用する場合、それらは静的または動的な方法（例えば、アドレス解決プロセス）でマッピングする必要があります。同様の要件も、サービスが運ばれるPIDおよびTSマルチプレックスを特定するために存在する場合があります。
Using an NPA address in an MPEG-2 TS may enhance security, in that a particular PDU may be targeted for a particular Receiver by specifying the corresponding Receiver NPA address. However, this is only a weak form of security, since the NPA filtering is often reconfigurable (frequently performed in software), and may be modified by a user to allow reception of specified (or all) packets, similar to promiscuous mode operation in Ethernet. If security is required, it should be applied at another place (e.g., link encryption, authentication of address resolution, IPsec, transport level security and/or application level security).
MPEG-2 TSでNPAアドレスを使用すると、特定のPDUが対応する受信機NPAアドレスを指定することにより、特定の受信機をターゲットにする可能性があるため、セキュリティが強化される場合があります。ただし、NPAフィルタリングはしばしば再構成可能で（ソフトウェアで頻繁に実行される）ことが多く、ユーザーが変更して、イーサネットでの無差別モード操作と同様に指定された（またはすべての）パケットの受信を許可するため、これは弱い形式のセキュリティです。セキュリティが必要な場合は、別の場所で適用する必要があります（例：リンク暗号化、住所解像度の認証、IPSEC、輸送レベルのセキュリティ、および/またはアプリケーションレベルのセキュリティ）。
There are also cases where the use of an NPA is required (e.g., where a system operates as a router) and, if present, this should be carried in an encapsulation header where it may be used by Receivers as a pre-filter to discard unwanted SNDUs. The addresses allocated do not need to conform to the IEEE MAC address format. There are many cases where an NPA is not required, and network layer filtering may be used. Therefore, a new encapsulation protocol should support an optional NPA.
また、NPAの使用が必要な場合（たとえば、システムがルーターとして動作する場合）、存在する場合は、これをカプセル化ヘッダーに持ち込んで、レシーバーが事前フィルターとして使用して不要なSNDUを廃棄することができます。割り当てられたアドレスは、IEEE Macアドレス形式に準拠する必要はありません。NPAが不要であり、ネットワークレイヤーフィルタリングを使用する場合があります。したがって、新しいカプセル化プロトコルは、オプションのNPAをサポートする必要があります。
For the IP service, the probability of undetected packet error should be small (or negligible) [RFC3819]. Therefore, there is a need for a strong integrity check (e.g., Cyclic Redundancy Check or CRC) to verify correctness of a received PDU [RFC3819]. Such checks should be sufficient to detect incorrect operation of the encapsulator and Receiver (including reassembly errors following loss/corruption of TS Packets), in addition to protecting from loss and/or corruption by the transmission network (e.g., multiplexors and links).
IPサービスの場合、検出されないパケットエラーの確率は小さく（または無視できる）[RFC3819]でなければなりません。したがって、受信したPDU [RFC3819]の正しさを検証するために、強力な完全性チェック（環状冗長チェックやCRCなど）が必要です。このようなチェックは、伝送ネットワーク（たとえば、マルチプレクサやリンクなど）による損失および/または腐敗から保護することに加えて、エンカプセーターとレシーバーの誤った動作（TSパケットの損失/腐敗後の再組み立てエラーを含む）を検出するのに十分でなければなりません。
Mechanisms exist in MPEG-2 Transmission Networks that may assist in detecting loss (e.g., the 4-bit continuity counter included in the MPEG-2 TS Packet header).
メカニズムは、MPEG-2伝送ネットワークに存在し、損失の検出に役立ちます（たとえば、MPEG-2 TSパケットヘッダーに含まれる4ビット連続性カウンター）。
An encapsulation must provide a strong integrity check for each IP packet. The requirements for usage of a link CRC are provided in [RFC3819]. To ease hardware implementation, this check should be carried in a trailer following the SNDU. A CRC-32 is sufficient for operation with up to a 12 KB payload, and may still provide adequate protection for larger payloads.
カプセル化は、IPパケットごとに強力な整合性チェックを提供する必要があります。リンクCRCの使用の要件は[RFC3819]に提供されています。ハードウェアの実装を容易にするために、このチェックは、SNDUに続いてトレーラーに携帯する必要があります。CRC-32は、最大12 kbのペイロードを備えた動作に十分であり、より大きなペイロードを適切な保護を提供する場合があります。
4.6. Identification of Scope.
4.6. 範囲の識別。
The MPE section header contains information that could be used by the Receiver to identify the scope of the (MAC) address carried as an NPA, and to prevent TS Packets intended for one scope from being received by another. Similar functionality may be achieved by ensuring that only IP packets that do not have overlapping scope are sent on the same TS Logical Channel. In some cases, this may imply the use of multiple TS Logical Channels.
MPEセクションヘッダーには、NPAとして運ばれる（MAC）アドレスの範囲を識別するためにレシーバーが使用できる情報が含まれており、あるスコープが別のスコープが受信するのを意図したTSパケットを防ぐために含まれています。同様の機能は、同じTS論理チャネルでオーバーラップスコープを持たないIPパケットのみが送信されるようにすることで実現できます。場合によっては、これは複数のTS論理チャネルの使用を意味する場合があります。
The evolution of the Internet service may require additional functions in the future. A flexible protocol should therefore provide a way to introduce new features when required, without having to provide additional out-of-band configuration.
インターネットサービスの進化には、将来の追加機能が必要になる場合があります。したがって、柔軟なプロトコルは、追加の帯域外構成を提供することなく、必要に応じて新しい機能を導入する方法を提供する必要があります。
IPv6 introduced the concept of extension headers that carry extra information necessary/desirable for certain subnetworks. The DOCSIS cable specification also allows a MAC header to carry extension headers to build operator-specific services. Thus, it is a requirement for the new encapsulation to allow extension headers.
IPv6は、特定のサブネットワークに必要/望ましい追加情報を運ぶ拡張ヘッダーの概念を導入しました。DocSISケーブル仕様により、Macヘッダーが拡張ヘッダーを運び、オペレーター固有のサービスを構築することができます。したがって、新しいカプセル化が拡張ヘッダーを可能にするための要件です。
The main requirements for an IP-centric encapsulation include:
IP中心のカプセル化の主な要件は次のとおりです。
- support of IPv4 and IPv6 packets - support for Ethernet encapsulated packets - flexibility to support other IP formats and protocols (e.g., ROHC, MPLS) - easy implementation using either hardware or software processing - low overhead/managed overhead - a fully specified algorithm that allows a sender to pack multiple packets per SNDU and to easily locate packet fragments - extensibility - compatibility with legacy deployments - ability to allow link encryption, when required - capability to support a full network architecture including data, control, and management planes
- IPv4およびIPv6パケットのサポート - イーサネットカプセル化されたパケットのサポート - 他のIP形式とプロトコル（ROHC、MPLSなど）をサポートする柔軟性 - ハードウェアまたはソフトウェア処理を使用した簡単な実装 - 低オーバーヘッド/マネージャーオーバーヘッド - SNDUにぴったりのパケットを配置することができるように、SNDUのパケットを簡単に配置することを可能にします。必要に応じてライプション - データ、制御、管理機などの完全なネットワークアーキテクチャをサポートする機能
Address Resolution (AR) provides a mechanism that associates layer 2 (L2) information with the IP address of a system [IPDVB-AR]. Many L2 technologies employ unicast AR at the sender: an IP system wishing to send an IP packet encapsulates it and places it into an L2 frame. It then identifies the appropriate L3 adjacency (e.g., next hop router, end host) and determines the appropriate L2 adjacency (e.g., MAC address in Ethernet) to which the frame should be sent so that the packet gets across the L2 link.
アドレス解像度（AR）は、レイヤー2（L2）情報をシステム[IPDVB-AR]のIPアドレスと関連付けるメカニズムを提供します。多くのL2テクノロジーは、送信者でユニキャストARを採用しています。IPパケットを送信したいIPシステムは、それをカプセル化し、L2フレームに配置します。次に、適切なL3隣接（次のホップルーター、エンドホストなど）を識別し、パケットがL2リンクを越えるようにフレームを送信する適切なL2隣接（イーサネットのMacアドレスなど）を決定します。
The L2 addresses discovered using AR are normally recorded in a data structure known as the arp/neighbor cache. The results of previous AR requests are usually cached. Further AR protocol exchanges may be required as communication proceeds to update or re-initialize the client cache state contents (i.e., purge/refresh the contents). For stability, and to allow network topology changes and client faults, the cache contents are normally "soft state"; that is, they are aged with respect to time and old entries are removed.
ARを使用して発見されたL2アドレスは、通常、ARP/隣接キャッシュとして知られるデータ構造に記録されます。以前のAR要求の結果は通常、キャッシュされます。通信がクライアントキャッシュ状態のコンテンツを更新または再発行するために進行するため、さらにARプロトコル交換が必要になる場合があります（つまり、コンテンツをパージ/更新します）。安定性、およびネットワークトポロジの変更とクライアントの障害を可能にするために、キャッシュの内容は通常「ソフト状態」です。つまり、時間に関して老化しており、古いエントリが削除されます。
In some cases (e.g., ATM, X.25, MPEG-2 and many more), AR involves finding other information than the MAC address. This includes identifying other parameters required for L2 transmission, such as channel IDs (VCs in X.25, VCIs in ATM, or PIDs in MPEG-2 TS).
場合によっては（ATM、X.25、MPEG-2など）、ARにはMACアドレス以外の情報を見つけることが含まれます。これには、チャネルID（X.25のVCS、ATMのVCIS、MPEG-2 TSのPID）など、L2伝送に必要な他のパラメーターの識別が含まれます。
Address resolution has different purposes for unicast and multicast. Multicast address resolution is not required for many L2 networks, but is required where MPEG-2 transmission networks carry IP multicast packets using more than one TS Logical Channel.
住所の解決には、ユニキャストとマルチキャストにはさまざまな目的があります。多くのL2ネットワークにはマルチキャストアドレス解像度は必要ありませんが、MPEG-2伝送ネットワークが複数のTS論理チャネルを使用してIPマルチキャストパケットを運ぶ場合が必要です。
There are three elements to the L2 information required to perform AR before an IP packet is sent over an MPEG-2 TS. These are:
IPパケットがMPEG-2 TSを介して送信される前に、ARを実行するために必要なL2情報には3つの要素があります。これらは：
(i) A Receiver ID (e.g., a 6B MAC/NPA address). (ii) A PID or index to find a PID. (iii) Tuner information (e.g., Transmit Frequency of the physical layer of a satellite/broadcast link
(i) レシーバーID（例：6B MAC/NPAアドレス）。（ii）PIDまたはPIDを見つけるためのPIDまたはインデックス。（iii）チューナー情報（たとえば、衛星/ブロードキャストリンクの物理層の送信周波数
Elements (ii) and (iii) need to be de-referenced when the MPEG-2 Transmission Network includes (re)multiplexors that renumber the PID values of the TS Logical Channels that they process. In MPEG-2 [ISO-MPEG], this dereferencing is via indexes to the information (i.e., the Program Map Table, PMT, which is itself indexed via the Program Association Table, PAT). (Note that PIDs are not intended to be end-to-end identifiers.) However, although remultiplexing is common in broadcast TV networks (scenarios A and B), many private networks do not need to employ multiplexors that renumber PIDs (see Section 3.3).
MPEG-2トランスミッションネットワークには、処理されるTS論理チャネルのPID値を変更する（RE）マルチプレクサが含まれている場合、要素（ii）および（iii）を参照する必要があります。MPEG-2 [ISO-MPEG]では、この命令は情報へのインデックスを介して行われます（つまり、プログラムアソシエーションテーブル、PATを介してインデックスが付けられているプログラムマップテーブルPMT）。（PIDはエンドツーエンドの識別子であることを意図していないことに注意してください。）ただし、ブロードキャストテレビネットワーク（シナリオAおよびB）では、再退屈は一般的ですが、多くのプライベートネットワークではPIDを変更するマルチプレクサを使用する必要はありません（セクション3.3を参照）。
The third element (iii) allows an AR client to resolve to a different MPEG TS Multiplex. This is used when there are several channels that may be used for communication (i.e., multiple outbound/inbound links). In a mesh system, this could be used to determine connectivity. This AR information is used in two ways at a Receiver:
3番目の要素（III）により、ARクライアントは別のMPEG TSマルチプレックスに解決できます。これは、通信に使用できるいくつかのチャネル（つまり、複数のアウトバウンド/インバウンドリンク）がある場合に使用されます。メッシュシステムでは、これを使用して接続を決定できます。このAR情報は、レシーバーで2つの方法で使用されます。
(i) AR resolves an IP unicast or IPv4 broadcast address to the (MPEG TS Multiplex, PID, MAC/NPA address). This allows the Receiver to set L2 filters to let traffic pass to the IP layer. This is used for unicast, and IPv4 subnet broadcast.
(i) ARは、IPユニキャストまたはIPv4ブロードキャストアドレスを（MPEG TS Multiplex、PID、MAC/NPAアドレス）に解決します。これにより、レシーバーはL2フィルターを設定して、トラフィックをIPレイヤーに通過させることができます。これは、UnicastおよびIPv4サブネットブロードキャストに使用されます。
(ii) AR resolves an IP multicast address to the (MPEG TS Multiplex, PID, MAC/NPA address), and allows the Receiver to set L2 filters enabling traffic to pass to the IP layer. A Receiver in an MPEG-2 TS Transmission Network needs to resolve the PID value and the tuning (if present) associated with a TS Logical Channel and (at least for unicast) the destination Receiver NPA address.
（ii）ARは、IPマルチキャストアドレスを（MPEG TS Multiplex、PID、MAC/NPAアドレス）に解決し、受信機がL2フィルターを設定してトラフィックをIPレイヤーに渡すことを可能にします。MPEG-2 TSトランスミッションネットワークの受信機は、PID値とTS論理チャネルに関連付けられたチューニング（存在する場合）を解決し、（少なくともユニキャストの場合）宛先レシーバーNPAアドレスを解決する必要があります。
A star topology MPEG-2 TS transmission network is illustrated below, with two Receivers receiving a forward broadcast channel sent by a Hub. (A mesh system has some additional cases.) The forward broadcast channel consists of a "TS Multiplex" (a single physical bearer) allowing communication with the terminals. These communicate using a set of return channels.
星トポロジMPEG-2 TS伝送ネットワークを以下に示します。2つの受信機がハブから送信されたフォワードブロードキャストチャネルを受信します。（メッシュシステムにはいくつかの追加のケースがあります。）フォワードブロードキャストチャネルは、ターミナルとの通信を可能にする「TSマルチプレックス」（単一の物理ベアラー）で構成されています。これらは、一連のリターンチャネルを使用して通信します。
Forward broadcast
MPEG-2 TS \
----------------X /-----\
/ / \
| Receiver|
/----------+ A |
/ \ /
/-----\ / \-----/
/ \ /
| Hub |/
| +\ /-----\
\ / \ / \
\-----/ \ | Receiver|
\-----------+ B |
\ /
\-----/
Figure 6: MPEG-2 Transmission Network with 2 Receivers
図6：2つのレシーバーを備えたMPEG-2トランスミッションネットワーク
There are three possibilities for unicast AR:
ユニキャストARには3つの可能性があります。
(1) A system at a Receiver, A, needs to resolve an address of a system that is at the Hub;
(1) レシーバーのシステム、Aは、ハブにあるシステムのアドレスを解決する必要があります。
(2) A system at a Receiver, A, needs to resolve an address that is at another Receiver, B;
(2) レシーバーのシステムAは、別のレシーバーにあるアドレスを解決する必要があります。
(3) A host at the Hub needs to resolve an address that is at a Receiver. The sender (encapsulation gateway), uses AR to provide the MPEG TS Multiplex, PID, MAC/NPA address for sending unicast, IPv4 subnet broadcast and multicast packets.
(3) ハブのホストは、受信機にあるアドレスを解決する必要があります。送信者（カプセル化ゲートウェイ）は、ARを使用して、Unicast、IPv4サブネットブロードキャスト、マルチキャストパケットを送信するために、MPEG TSマルチプレックス、PID、MAC/NPAアドレスを提供します。
If the Hub is an IP router, then case (1) and (2) are the same: The host at the Receiver does not know the difference. In these cases, the address to be determined is the L2 address of the device at the Hub to which the IP packet should be forwarded, which then relays the IP packet back to the forward (broadcast) MPEG-2 channel after AR (case 3).
ハブがIPルーターの場合、ケース（1）と（2）は同じです。レシーバーのホストは違いを知りません。これらの場合、決定されるアドレスは、IPパケットを転送するハブのデバイスのL2アドレスであり、ARの後にIPパケットをフォワード（ブロードキャスト）MPEG-2チャネルにリリーします（ケース3）。
If the Hub is an L2 bridge, then case 2 still has to relay the IP packet back to the outbound MPEG-2 channel. The AR protocol needs to resolve the specific Receiver L2 MAC address of B, but needs to send this on an L2 channel to the Hub. This requires Receivers to be informed of the L2 address of other Receivers.
ハブがL2ブリッジである場合、ケース2はまだIPパケットをアウトバウンドMPEG-2チャネルに戻す必要があります。ARプロトコルは、Bの特定のレシーバーL2 MACアドレスを解決する必要がありますが、L2チャネルでこれをハブに送信する必要があります。これには、他の受信機のL2アドレスを受信者に通知する必要があります。
An end host connected to the Hub needs to use the AR protocol to resolve the Receiver terminal MAC/NPA address. This requires the AR server at the Hub to be informed of the L2 addresses of other Receivers.
ハブに接続されたエンドホストは、ARプロトコルを使用してレシーバー端子MAC/NPAアドレスを解決する必要があります。これには、ハブのARサーバーに他の受信機のL2アドレスを通知する必要があります。
An AR protocol may transmit AR information in three distinct ways:
ARプロトコルは、AR情報を3つの異なる方法で送信する場合があります。
(i) An MPEG-2 signalling table transmitted at the MPEG-2 level (e.g., within the control plane using a Table);
(i) MPEG-2レベルで送信されたMPEG-2シグナル伝達テーブル（たとえば、テーブルを使用してコントロールプレーン内）;
(ii) An MPEG-2 signalling table transmitted at the IP level (no implementations of this are known);
（ii）IPレベルで送信されるMPEG-2シグナル伝達テーブル（これの実装は既知ではありません）。
(iii) An address resolution protocol transported over IP (as in ND for IPv6)
（iii）IPを介して輸送されたアドレス解像度プロトコル（IPv6のNDのように）
There are three distinct cases in which AR may be used:
ARを使用できる3つの異なるケースがあります。
(i) Multiple TS-Muxes and the use of re-multiplexors, e.g., Digital Terrestrial, Satellite TV broadcast multiplexes. Many such systems employ remultiplexors that modify the PID values associated with TS Logical Channels as they pass through the MPEG-2 transmission network (as in Scenario A of Section 3.1).
(i) 複数のTS-Muxと再マルチプレクサーの使用、たとえば、デジタル地上、衛星テレビブロードキャストマルチプレックス。このようなシステムの多くは、TS論理チャネルに関連付けられたPID値をMPEG-2トランスミッションネットワークを通過するときに変更するRemultiplexorsを使用しています（セクション3.1のシナリオAのように）。
(ii) Tuner configuration(s) that are fixed or controlled by some other process. In these systems, the PID value associated with a TS Logical Channel may be known by the Sender.
（ii）他のプロセスによって固定または制御されるチューナー構成。これらのシステムでは、TS論理チャネルに関連付けられたPID値は、送信者によって知られている場合があります。
(iii) A service run over one TS Mux (i.e., uses only one PID, for example DOCSIS and some current DVB-RCS multicast systems). In these systems, the PID value of a TS Logical Channel may be known by the Sender.
（iii）1つのTS MUXを介して実行されるサービス（つまり、DOCSISと現在のDVB-RCSマルチキャストシステムなど、1つのPIDのみを使用します）。これらのシステムでは、TS論理チャネルのPID値は送信者によって知られている場合があります。
In current deployments of MPEG-2 networks, information about the set of MPEG-2 TS Logical Channels carried over a TS Multiplex is usually distributed via tables (service information, SI) sent using channels assigned a specific (well-known) set of PIDs. This was originally designed for audio/video distribution to STBs. This design requires access to the control plane by processing the SI table information (carried in MPEG-2 section format [ISO-DSMCC]). The scheme reflects the complexity of delivering and coordinating the various TS Logical Channels associated with a multimedia TV program.
MPEG-2ネットワークの現在の展開では、TSマルチプレックスに搭載されたMPEG-2 TS論理チャネルのセットに関する情報は、通常、PIDの特定（よく知られている）セットを割り当てられたチャネルを使用して送信されるテーブル（サービス情報、SI）を介して配布されます。これはもともと、STBへのオーディオ/ビデオ配信用に設計されていました。この設計では、SIテーブル情報（MPEG-2セクション形式[ISO-DSMCC]で伝達される）を処理することにより、制御プレーンにアクセスする必要があります。このスキームは、マルチメディアTVプログラムに関連するさまざまなTS論理チャネルを提供および調整する複雑さを反映しています。
One possible requirement to provide TS multiplex and PID information for IP services is to integrate additional information into the existing MPEG-2 tables, or to define additional tables specific to the IP service. The DVB INT and the A/92 Specification from ATSC [ATSC-A92] are examples of the realization of such a solution.
IPサービスにTSマルチプレックスとPID情報を提供するための1つの考えられる要件は、追加情報を既存のMPEG-2テーブルに統合するか、IPサービスに固有の追加テーブルを定義することです。DVB INTおよびATSC [ATSC-A92]からのA/92仕様は、そのようなソリューションの実現の例です。
AR information could be carried over a TS data channel (e.g., using an IP protocol similar to the Service Announcement Protocol, SAP). Implementing this independently of the SI tables would ease implementation, by allowing it to operate on systems where IP processing is performed in a software driver. It may also allow the technique to be more easily adapted to other similar delivery networks. It also is advantageous for networks that use the MPEG-2 TS, but do not necessarily support audio/video services and therefore do not need to provide interoperability with TV equipment (e.g., links used solely for connecting IP (sub)networks).
AR情報は、TSデータチャネルに掲載される可能性があります（たとえば、サービスアナウンスプロトコル、SAPと同様のIPプロトコルを使用）。これをSIテーブルとは独立して実装すると、ソフトウェアドライバーでIP処理が実行されるシステムで動作できるようにすることで、実装を容易にします。また、この手法を他の同様の配信ネットワークにより簡単に適合させることができます。また、MPEG-2 TSを使用するネットワークにとっても有利ですが、必ずしもオーディオ/ビデオサービスをサポートするわけではないため、テレビ機器（例えば、IP（サブ）ネットワークの接続にのみ使用されるリンク）と相互運用性を提供する必要はありません。
A query/response protocol may be used at the IP level (similar to, or based on IPv6 Neighbor Advertisements of the ND protocol). The AR protocol may operate over an MPEG-2 TS Logical Channel using a previously agreed PID (e.g., configured, or communicated using a SI table). In this case, the AR could be performed by the target system itself (as in ARP and ND). This has good soft-state properties, and is very tolerant to failures. To find an address, a system sends a "query" to the network, and the "target" (or its proxy) replies.
クエリ/応答プロトコルは、IPレベルで使用できます（NDプロトコルのIPv6隣接広告に類似または基づいています）。ARプロトコルは、以前に合意したPIDを使用してMPEG-2 TS論理チャネルを介して動作する場合があります（たとえば、SIテーブルを使用して構成または通信）。この場合、ARはターゲットシステム自体（ARPおよびNDのように）によって実行できます。これには優れたソフトステート特性があり、障害に非常に寛容です。アドレスを見つけるために、システムはネットワークに「クエリ」を送信し、「ターゲット」（またはそのプロキシ）の返信を送信します。
In some cases, an MPEG-2 Transmission Network may support multiple IP networks. When this is the case, it is important to recognize the context (scope) within which an address is resolved, to prevent packets from one addressed scope from leaking into other scopes.
場合によっては、MPEG-2トランスミッションネットワークが複数のIPネットワークをサポートする場合があります。この場合、アドレスが解決されるコンテキスト（スコープ）を認識し、1つのアドレス指定されたスコープから他のスコープに漏れないようにするために、コンテキスト（スコープ）を認識することが重要です。
An example of overlapping IP address assignments is the use of private unicast addresses (e.g., in IPv4, 10/8 prefix; 172.16/12 prefix; 192.168/16 prefix). These should be confined to the area to which they are addressed.
重複するIPアドレスの割り当ての例は、プライベートユニキャストアドレスの使用です（例：IPv4、10/8プレフィックス、172.16/12プレフィックス、192.168/16プレフィックス）。これらは、対処されている領域に限定する必要があります。
There is also a requirement for multicast address scoping (Section 6.2).
マルチキャストアドレススコープの要件もあります（セクション6.2）。
IP packets with these addresses must not be allowed to travel outside their intended scope, and may cause unexpected behaviour if allowed to do so. In addition, overlapping address assignments can arise when using level 2 NPA addresses:
これらのアドレスを備えたIPパケットは、意図した範囲外に移動することを許可されてはならず、そうすることを許可された場合、予期しない動作を引き起こす可能性があります。さらに、レベル2 NPAアドレスを使用すると、アドレスの重複割り当てが発生する可能性があります。
(i) The NPA address must be unique within the TS Logical Channel. Universal IEEE MAC addresses used in Ethernet LANs are globally unique. If the NPA addresses are not globally unique, the same NPA address may be re-used by Receivers in different addressed areas.
(i) NPAアドレスは、TS論理チャネル内で一意でなければなりません。イーサネットLANで使用されるユニバーサルIEEE MACアドレスは、グローバルにユニークです。NPAアドレスがグローバルに一意ではない場合、同じNPAアドレスが異なるアドレス指定された領域の受信機によって再利用される場合があります。
(ii) The NPA broadcast address (all 1s MAC address). Traffic with this address should be confined to one addressed area.
（ii）NPAブロードキャストアドレス（すべての1S Macアドレス）。このアドレスを使用したトラフィックは、1つのアドレス指定された領域に限定する必要があります。
Reception of unicast packets destined for another addressed area may lead to an increase in the rate of received packets by systems connected via the network. IP end hosts normally filter received unicast IP packets based on their assigned IP address. Reception of the additional network traffic may contribute to processing load but should not lead to unexpected protocol behaviour. However, it does introduce a potential Denial of Service (DoS) opportunity.
別のアドレス指定された領域に向けられたユニキャストパケットの受信は、ネットワークを介して接続されたシステムによって受信されたパケットのレートの増加につながる可能性があります。IPエンドホストは通常、割り当てられたIPアドレスに基づいて受信したユニキャストIPパケットをフィルターします。追加のネットワークトラフィックの受信は、処理負荷に寄与する可能性がありますが、予期しないプロトコル動作につながることはありません。ただし、潜在的なサービス拒否（DOS）の機会を導入します。
When the Receiver acts as an IP router, the receipt of such an IP packet may lead to unexpected protocol behaviour. This also provides a security vulnerability since arbitrary packets may be passed to the IP layer.
受信機がIPルーターとして機能する場合、そのようなIPパケットの受領は予期しないプロトコル動作につながる可能性があります。これは、任意のパケットがIPレイヤーに渡される可能性があるため、セキュリティの脆弱性も提供します。
In many AR designs, authentication has been overlooked because of the wired nature of most existing IP networks, which makes it easy to control hosts that are physically connected [RFC3819]. With wireless connections, this is changing: unauthorized hosts actually can claim L2 resources. The address resolution client (i.e., Receiver) may also need to verify the integrity and authenticity of the AR information that it receives. There are trust relationships both ways: clients need to know they have a valid server and that the resolution is valid. Servers should perform authorisation before they allow an L2 address to be used.
多くのAR設計では、ほとんどの既存のIPネットワークの有線性のために認証が見落とされています。これにより、物理的に接続されたホストを簡単に制御できます[RFC3819]。ワイヤレス接続を使用すると、これは変化しています。不正なホストは実際にL2リソースを請求できます。アドレス解決クライアント（つまり、受信者）は、受け取ったAR情報の整合性と信頼性を検証する必要もあります。両方の方法で信頼関係があります。クライアントは、有効なサーバーを持っていることを知る必要があり、解像度が有効であることを知る必要があります。サーバーは、L2アドレスを使用できるようにする前に承認を実行する必要があります。
The MPEG-2 Transmission Network may also require access control to prevent unauthorized use of the TS Multiplex; however, this is an orthogonal issue to address resolution.
MPEG-2トランスミッションネットワークは、TSマルチプレックスの不正使用を防ぐためにアクセス制御を必要とする場合もあります。ただし、これは解決に対処するための直交問題です。
The requirement for AR over MPEG-2 networks include:
MPEG-2ネットワークを介したARの要件は次のとおりです。
(i) Use of a table-based approach to promote AR scaling. This requires definition of the frequency of update and volume of AR traffic generated.
(i) ARスケーリングを促進するためのテーブルベースのアプローチの使用。これには、更新の頻度と生成されたARトラフィックの量の定義が必要です。
(ii) Mechanisms to install AR information at the server (unsolicited registration).
（ii）サーバーにAR情報をインストールするメカニズム（未承諾登録）。
(iii) Mechanisms to verify AR information held at the server (solicited responses). Appropriate timer values need to be defined.
（iii）サーバーに保持されているAR情報を検証するメカニズム（応答を求められます）。適切なタイマー値を定義する必要があります。
(iv) An ability to purge client AR information (after IP network renumbering, etc.).
（iv）クライアントAR情報をパージする能力（IPネットワークの変更など）。
(v) Support of IP subnetwork scoping.
(v) IPサブネットワークスコーピングのサポート。
(vi) Appropriate security associations to authenticate the sender.
（vi）送信者を認証するための適切なセキュリティ協会。
This section addresses specific issues concerning IPv4 and IPv6 multicast [RFC1112] over MPEG-2 Transmission Networks. The primary goal of multicast support will be efficient filtering of IP multicast packets by the Receiver, and the mapping of IPv4 and IPv6 multicast addresses [RFC3171] to the associated PID value and TS Multiplex.
このセクションでは、MPEG-2トランスミッションネットワークを介したIPv4およびIPv6マルチキャスト[RFC1112]に関する特定の問題について説明します。マルチキャストサポートの主な目標は、受信機によるIPマルチキャストパケットの効率的なフィルタリング、および関連するPID値とTSマルチプレックスに対するIPv4およびIPv6マルチキャストアドレス[RFC3171]のマッピングです。
The design should permit a large number of active multicast groups, and should minimize the processing load at the Receiver when filtering and forwarding IP multicast packets. For example, schemes that may be easily implemented in hardware would be beneficial, since these may relieve drivers and operating systems from discarding unwanted multicast traffic [RFC3819].
この設計では、多数のアクティブなマルチキャストグループが許可され、IPマルチキャストパケットをフィルタリングおよび転送するときに受信機の処理負荷を最小限に抑える必要があります。たとえば、ハードウェアに簡単に実装できるスキームは有益です。これらは、ドライバーとオペレーティングシステムが望ましくないマルチキャストトラフィックを破棄することを緩和する可能性があるためです[RFC3819]。
Multicast mechanisms are used at more than one protocol level. The upstream router feeding the MPEG-2 Encapsulator may forward multicast traffic on the MPEG-2 TS Multiplex using a static or dynamic set of groups. When static forwarding is used, the set of IP multicast groups may also be configured or set using SNMP, Telnet, etc. A Receiver normally uses either an IP group management protocol (IGMP [RFC3376] for IPv4 or MLD [RFC2710][RFC3810] for IPv6) or a multicast routing protocol to establish tables that it uses to dynamically enable local forwarding of received groups. In a dynamic case, this group membership information is fed back to the sender to enable it to start sending new groups and (if required) to update the tables that it produces for multicast AR.
マルチキャストメカニズムは、複数のプロトコルレベルで使用されます。MPEG-2カプセレータに供給するアップストリームルーターは、静的または動的なグループセットを使用してMPEG-2 TSマルチプレックスのマルチキャストトラフィックを転送できます。静的転送を使用する場合、IPマルチキャストグループのセットは、SNMP、Telnetなどを使用して設定または設定することもできます。レシーバーは通常、IPグループ管理プロトコル（IPV4 [RFC3376]またはMLD [RFC2710] [RFC2710] [RFC3810]を使用して、IPV6を使用します。動的な場合、このグループメンバーシップ情報は送信者に返還され、新しいグループの送信を開始し、（必要に応じて）マルチキャストAR用に生成されるテーブルを更新します。
Appropriate procedures need to identify the correct action when the same multicast group is available on more than one TS Logical Channel. This could arise when different end hosts act as senders to contribute IP packets with the same IP group destination address. The correct behaviour for SSM [RFC3569] addresses must also be considered. It may also arise when a sender duplicates the same IP group over several TS Logical Channels (or even different TS Multiplexes), and in this case a Receiver may potentially receive more than one copy of the same packet. At the IP level, the host/router may be unaware of this duplication.
同じマルチキャストグループが複数のTS論理チャネルで利用可能である場合、適切な手順を正しいアクションを特定する必要があります。これは、異なるエンドホストが送信者として機能して、同じIPグループの宛先アドレスを持つIPパケットを提供する場合に発生する可能性があります。SSM [RFC3569]アドレスの正しい動作も考慮する必要があります。また、送信者がいくつかのTS論理チャネル（または異なるTSマルチプレックス）で同じIPグループを複製し、この場合、レシーバーが同じパケットの複数のコピーを受信する可能性がある場合にも発生する可能性があります。IPレベルでは、ホスト/ルーターがこの複製に気付いていない場合があります。
The functions required for multicast AR may be summarized as:
マルチキャストARに必要な機能は、次のように要約できます。
(i) The Sender needs to know the L2 mapping of a multicast group. (ii) The Receiver needs to know the L2 mapping of a multicast group.
(i) 送信者は、マルチキャストグループのL2マッピングを知る必要があります。（ii）レシーバーは、マルチキャストグループのL2マッピングを知る必要があります。
In the Internet, multicast AR is normally a mapping function rather than a one-to-one association using a protocol. In Ethernet, the sender maps an IP address to an L2 MAC address, and the Receiver uses the same mapping to determine the L2 address to set an L2 hardware/software filter entry.
インターネットでは、マルチキャストARは通常、プロトコルを使用した1対1の関連付けではなく、マッピング関数です。イーサネットでは、送信者はIPアドレスをL2 MACアドレスにマッピングし、レシーバーは同じマッピングを使用してL2アドレスを決定し、L2ハードウェア/ソフトウェアフィルターエントリを設定します。
A typical sequence of actions for the dynamic case is:
動的なケースの典型的な一連のアクションは次のとおりです。
L3) Populate the IP L3 membership tables at the Receiver.
L3）受信機にIP L3メンバーシップテーブルに入力します。
L3) Receivers send/forward IP L3 membership tables to the Hub
L3）受信者は、IP L3メンバーシップテーブルをハブに送信/転送
L3) Dynamic/static forwarding at hub/upstream router of IP L3 groups
L3）IP L3グループのハブ/アップストリームルーターでの動的/静的転送
L2) Populate the IP AR tables at the encapsulator gateway (i.e., Map IP L3 mcast groups to L2 PIDs)
L2）Encapsulator GatewayにIP ARテーブルを入力します（つまり、IP L3 MCASTグループをL2 PIDにマップします）
L2) Distribute the AR information to Receivers
L2）AR情報を受信機に配布します
L2) Set Receiver L2 multicast filters for IP groups in the membership table.
L2）メンバーシップテーブルのIPグループのレシーバーL2マルチキャストフィルターを設定します。
To be flexible, AR must associate a TS Logical Channel (PID) not only with a group address, but possibly also a QoS class and other appropriate MPEG-2 TS attributes. Explicit per group AR to individual L2 addresses is to be avoided.
柔軟性があるため、ARはTS論理チャネル（PID）をグループアドレスだけでなく、QoSクラスやその他の適切なMPEG-2 TS属性に関連付ける必要があります。グループごとのARごとの個々のL2アドレスへの明示的なARは避けます。
\
|
+---+----+ +---------+
| Tuner |---+TS Table | . . . .
+---+----+ +---------+ .
| - .
+--------+ +---------+ .
| deMux |---+PID Table|........
+---+----+ +---------+ :
| - :
+--------+ +---------+ +------------+
|MPE/ULE |---+AR Cache-|---+ L2 Table |
+---+----+ +---------+ +------------+
| | |
+---+----+ +---+-----+ +---+----+
| IP | | AR | |IGMP/MLD|
+---+----+ +---+-----+ +---+----+
| | |
*------------+------------+
Figure 7: Receiver Processing Architecture
図7：受信機処理アーキテクチャ
As in unicast, it is important to recognize the context (scope) within which a multicast IP address is resolved, to prevent packets from one addressed scope leaking into other scopes.
ユニキャストのように、マルチキャストIPアドレスが解決されるコンテキスト（スコープ）を認識して、アドレス指定されたスコープが他のスコープに漏れているのを防ぐことが重要です。
Examples of overlapping IP multicast address assignments include:
重複するIPマルチキャストアドレスの割り当ての例は次のとおりです。
(i) Local scope multicast addresses. These are only valid within the local area (examples for IPv4 include: 224.0.0/24; 224.0.1/24). Similar cases exist for some IPv6 multicast addresses [RFC2375].
(i) ローカルスコープマルチキャストアドレス。これらはローカルエリア内でのみ有効です（IPv4の例には、224.0.0/24; 224.0.1/24）。一部のIPv6マルチキャストアドレス[RFC2375]についても同様のケースが存在します。
(ii) Scoped multicast addresses [RFC2365] [RFC 2375]. Forwarding of these addresses is controlled by the scope associated with the address. The addresses are only valid with an addressed area (e.g. the 239/8 [RFC2365]).
（ii）スコープされたマルチキャストアドレス[RFC2365] [RFC 2375]。これらのアドレスの転送は、アドレスに関連付けられたスコープによって制御されます。アドレスは、アドレス指定された領域でのみ有効です（例：239/8 [RFC2365]）。
(iii) Other non-IP protocols may also view sets of MAC multicast addresses as link-local, and may produce unexpected results if distributed across several private networks.
（iii）他の非IPプロトコルは、MacマルチキャストアドレスのセットをLink-Localと見なすこともあり、いくつかのプライベートネットワークに配布された場合、予期しない結果を生成する場合があります。
IP packets with these addresses must not be allowed to travel outside their intended scope (see Section 5.3). Performing multicast AR at the IP level can enable providers to offer independently scoped addresses and would need to use multiple Multicast AR servers, one per multicast domain.
これらのアドレスを備えたIPパケットは、意図した範囲外に移動することを許可してはなりません（セクション5.3を参照）。IPレベルでマルチキャストARを実行すると、プロバイダーが独立してスコープされたアドレスを提供できるため、マルチキャストドメインごとに複数のマルチキャストARサーバーを使用する必要があります。
The requirements for supporting multicast include, but are not restricted to:
マルチキャストをサポートするための要件には、以下が含まれますが、制限されていません。
(i) Encapsulating multicast packets for transmission using an MPEG-2 TS.
(i) MPEG-2 TSを使用した送信用のマルチキャストパケットのカプセル化。
(ii) Mapping IP multicast groups to the underlying MPEG-2 TS Logical Channel (PID) and the MPEG-2 TS Multiplex.
（ii）IPマルチキャストグループを基礎となるMPEG-2 TS論理チャネル（PID）およびMPEG-2 TSマルチプレックスにマッピングします。
(iii) Providing AR information to allow a Receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex.
（iii）AR情報を提供して、受信者がMPEG-2 TSマルチプレックス内のIPマルチキャストフローを見つけることができるようにします。
(iv) Error Reporting.
（iv）エラー報告。
This document describes the architecture for a set of protocols to perform efficient and flexible support for IP network services over networks built upon the MPEG-2 Transport Stream (TS). It also describes existing approaches. The focus is on IP networking, the mechanisms that are used, and their applicability to supporting IP unicast and multicast services.
このドキュメントでは、MPEG-2 Transport Stream（TS）に基づいて構築されたネットワークを介してIPネットワークサービスを効率的かつ柔軟なサポートを実行するための一連のプロトコルのアーキテクチャについて説明します。また、既存のアプローチについても説明しています。焦点は、IPネットワーキング、使用されるメカニズム、およびIPユニキャストおよびマルチキャストサービスをサポートするための適用性にあります。
The requirements for a new encapsulation of IPv4 and IPv6 packets is described, outlining the limitations of current methods and the need for a streamlined IP-centric approach.
IPv4およびIPv6パケットの新しいカプセル化の要件について説明し、現在の方法の制限と合理化されたIP中心のアプローチの必要性を概説します。
The architecture also describes MPEG-2 Address Resolution (AR) procedures to allow dynamic configuration of the sender and Receiver using an MPEG-2 transmission link/network. These support IPv4 and IPv6 services in both the unicast and multicast modes. Resolution protocols will support IP packet transmission using both the Multiprotocol Encapsulation (MPE), which is currently widely deployed, and also any IETF-defined encapsulation (e.g., ULE [IPDVB-ULE]).
アーキテクチャでは、MPEG-2アドレス解像度（AR）手順についても説明して、MPEG-2トランスミッションリンク/ネットワークを使用して送信者と受信機の動的な構成を許可します。これらは、ユニキャストモードとマルチキャストモードの両方でIPv4およびIPv6サービスをサポートしています。解像度プロトコルは、現在広く展開されているマルチプロトコルカプセル化（MPE）と、IETF定義のカプセル化（ule [ipdvb-ule]など）の両方を使用して、IPパケット伝送をサポートします。
When the MPEG-2 transmission network is not using a wireline network, the normal security issues relating to the use of wireless links for transport of Internet traffic should be considered [RFC3819].
MPEG-2トランスミッションネットワークがWirelineネットワークを使用していない場合、インターネットトラフィックの輸送のためのワイヤレスリンクの使用に関する通常のセキュリティの問題を考慮する必要があります[RFC3819]。
End-to-end security (including confidentiality, authentication, integrity and access control) is closely associated with the end user assets that are protected. This close association cannot be ensured when providing security mechanisms only within a subnetwork (e.g., an MPEG-2 Transmission Network). Several security mechanisms that can be used end-to-end have already been deployed in the general Internet and are enjoying increasing use. Important examples include:
エンドツーエンドのセキュリティ（機密性、認証、整合性、アクセス制御を含む）は、保護されているエンドユーザー資産と密接に関連しています。サブネットワーク内でのみセキュリティメカニズムを提供する場合（例：MPEG-2トランスミッションネットワーク）、この密接な関連性を確保することはできません。エンドツーエンドを使用できるいくつかのセキュリティメカニズムは、すでに一般的なインターネットに展開されており、使用が増えています。重要な例は次のとおりです。
- Transport Layer Security (TLS), which is primarily used to protect web commerce;
- 輸送層セキュリティ（TLS）。これは主にWebコマースの保護に使用されます。
- Pretty Good Privacy (PGP) and S/MIME, primarily used to protect and authenticate email and software distributions;
- かなり良いプライバシー（PGP）とS/MIMEは、主に電子メールとソフトウェアの分布を保護および認証するために使用されます。
- Secure Shell (SSH), used to secure remote access and file transfer;
- リモートアクセスとファイル転送を保護するために使用されるセキュアシェル（SSH）。
- IPsec, a general purpose encryption and authentication mechanism above IP that can be used by any IP application.
- IPSEC、IPアプリケーションで使用できるIPより上の汎用暗号化と認証メカニズム。
However, subnetwork security is also important [RFC3819] and should be encouraged, on the principle that it is better than the default situation, which all too often is no security at all. Users of especially vulnerable subnets (such as radio/broadcast networks and/or shared media Internet access) often have control over, at most, one endpoint - usually a client - and therefore cannot enforce the use of end-to-end mechanisms.
ただし、サブネットワークのセキュリティも重要であり[RFC3819]、デフォルトの状況よりも優れているという原則として、奨励する必要があります。特に脆弱なサブネット（ラジオ/ブロードキャストネットワークや共有メディアインターネットアクセスなど）のユーザーは、せいぜい1つのエンドポイント（通常はクライアント）を制御するため、エンドツーエンドのメカニズムの使用を強制することはできません。
A related role for subnetwork security is to protect users against traffic analysis, i.e., identifying the communicating parties (by IP or MAC address) and determining their communication patterns, even when their actual contents are protected by strong end-to-end security mechanisms. (This is important for networks such as broadcast/radio, where eavesdropping is easy.)
サブネットワークのセキュリティに関連する役割は、ユーザーをトラフィック分析から保護すること、つまり、実際のコンテンツが強力なエンドツーエンドのセキュリティメカニズムによって保護されている場合でも、通信当事者（IPまたはMacアドレス）を特定し、通信パターンを決定することです。（これは、盗聴が簡単なブロードキャスト/ラジオなどのネットワークにとって重要です。）
Encryption performed at the Transport Stream (encrypting the payload of all TS-Packets with the same PID) encrypts/scrambles all parts of the SNDU, including the layer 2 MAC/NPA address. Encryption at the section level in MPE may also optionally encrypt the layer 2 MAC/NPA address in addition to the PDU data [ETSI-DAT]. In both cases, encryption of the MAC/NPA address requires a Receiver to decrypt all encrypted data, before it can then filter the PDUs with the set of MAC/NPA addresses that it wishes to receive. This method also has the drawback that all Receivers must share a common encryption key. Encryption of the MPE MAC address is therefore not permitted in some systems (e.g., [ETSI-DVBRCS]).
輸送ストリームで実行された暗号化（同じPIDですべてのTSパケットのペイロードを暗号化する）は、レイヤー2 MAC/NPAアドレスを含むSNDUのすべての部分を暗号化/スクランブルします。MPEのセクションレベルでの暗号化は、PDUデータ[ETSI-DAT]に加えて、オプションでレイヤー2 MAC/NPAアドレスを暗号化する場合があります。どちらの場合も、MAC/NPAアドレスの暗号化では、受信したいデータを復号化する前に、受信者がすべての暗号化されたデータを復号化する必要があります。その後、受信したいMAC/NPAアドレスのセットでPDUをフィルタリングできます。この方法には、すべての受信機が共通の暗号化キーを共有する必要があるという欠点もあります。したがって、MPE MACアドレスの暗号化は、一部のシステムでは許可されていません（例：[ETSI-DVBRCS]）。
Where it is possible for an attacker to inject traffic into the subnetwork control plane, subnetwork security can additionally protect the subnetwork assets. This threat must specifically be considered for the protocols used for subnetwork control functions (e.g., address resolution, management, configuration). Possible threats include theft of service and denial of service; shared media subnets tend to be especially vulnerable to such attacks [RFC3819].
攻撃者がサブネットワーク制御プレーンにトラフィックを注入できる場合、サブネットワークのセキュリティはサブネットワーク資産をさらに保護できます。この脅威は、サブネットワーク制御関数に使用されるプロトコル（アドレス解像度、管理、構成など）について特に考慮する必要があります。考えられる脅威には、サービスの盗難とサービスの拒否が含まれます。共有メディアサブネットは、そのような攻撃に対して特に脆弱である傾向があります[RFC3819]。
Appropriate security functions must therefore be provided for IPDVB control protocols [RFC3819], particularly when the control functions are provided above the IP-layer using IP-based protocols. Internet level security mechanisms (e.g., IPsec) can mitigate such threats.
したがって、特にIPベースのプロトコルを使用してIP層の上に制御機能が提供される場合、IPDVB制御プロトコル[RFC3819]に適切なセキュリティ関数を提供する必要があります。インターネットレベルのセキュリティメカニズム（IPSECなど）は、そのような脅威を軽減できます。
In general, End-to-End security is recommended for users of any communication path, especially when it includes a wireless/radio or broadcast link, where a range of security techniques already exist. Specification of security mechanisms at the application layer, or within the MPEG-2 transmission network, are the concerns of organisations beyond the IETF. The complexity of any such security mechanisms should be considered carefully so that it will not unduly impact IP operations.
一般に、特にさまざまなセキュリティテクニックが既に存在するワイヤレス/ラジオまたはブロードキャストリンクが含まれる場合、通信パスのユーザーにはエンドツーエンドのセキュリティが推奨されます。アプリケーションレイヤーまたはMPEG-2トランスミッションネットワーク内でのセキュリティメカニズムの仕様は、IETFを超えた組織の懸念です。そのようなセキュリティメカニズムの複雑さは、IP操作に不当に影響を与えないように慎重に考慮する必要があります。
Link level encryption of IP traffic is commonly used in broadcast/radio links to supplement End-to-End security (e.g., provided by TLS, SSH, Open PGP, S/MIME, IPsec). The encryption and key exchange methods vary significantly, depending on the intended application. For example, DVB-S/DVB-RCS operated by Access Network Operators may wish to provide their customers (Internet Service Providers, ISP) with security services. Common security services are: terminal authentication and data confidentiality (for unicast and multicast) between an encapsulation gateway and Receivers. A common objective is to provide the same level of privacy as terrestrial links. An ISP may also wish to provide end-to-end security services to the end-users (based on well-known mechanisms such as IPsec).
IPトラフィックのリンクレベル暗号化は、一般的にブロードキャスト/無線リンクで使用され、エンドツーエンドのセキュリティをサプリメントします（たとえば、TLS、SSH、Open PGP、S/MIME、IPSECによって提供されます）。暗号化とキー交換方法は、意図したアプリケーションによって大きく異なります。たとえば、アクセスネットワークオペレーターが運営するDVB-S/DVB-RCは、顧客（インターネットサービスプロバイダー、ISP）にセキュリティサービスを提供したい場合があります。一般的なセキュリティサービスは次のとおりです。カプセル化ゲートウェイと受信機の間の端末認証とデータの機密性（ユニキャストとマルチキャスト用）。一般的な目的は、地上リンクと同じレベルのプライバシーを提供することです。ISPは、エンドユーザーにエンドツーエンドのセキュリティサービスを提供したい場合もあります（IPSECなどのよく知られているメカニズムに基づいています）。
Therefore, it is important to understand that both security solutions (Access Network Operators to ISP and ISP to end-users) may coexist.
したがって、両方のセキュリティソリューション（ISPへのネットワークオペレーターとISPへのISPへのエンドユーザーへのアクセス）の両方が共存する可能性があることを理解することが重要です。
MPE supports optional link encryption [ETSI-DAT]. A pair of bits within the MPE protocol header indicate whether encryption (scrambling) is used. For encrypted PDUs, the header bits indicate which of a pair of previously selected encryption keys is to be used.
MPEは、オプションのリンク暗号化[ETSI-DAT]をサポートしています。MPEプロトコルヘッダー内のビットのペアは、暗号化（スクランブル）が使用されているかどうかを示します。暗号化されたPDUの場合、ヘッダービットは、以前に選択した暗号化キーのペアのどれを使用するかを示します。
It is recommended that any new encapsulation defined by the IETF allows Transport Stream encryption and also supports optional link level encryption/authentication of the SNDU payload. In ULE [IPDVB-ULE], this may be provided in a flexible way using Extension Headers. This requires definition of a mandatory header extension, but has the advantage that it decouples specification of the security functions from the encapsulation functions. This method also supports encryption of the NPA/MAC addresses.
IETFによって定義された新しいカプセル化により、トランスポートストリームの暗号化が許可され、SNDUペイロードのオプションのリンクレベル暗号化/認証もサポートすることをお勧めします。ule [ipdvb-ule]では、これは拡張ヘッダーを使用して柔軟な方法で提供される場合があります。これには、必須のヘッダー拡張機能の定義が必要ですが、カプセル化関数からのセキュリティ関数の仕様を切り離すという利点があります。この方法は、NPA/MACアドレスの暗号化もサポートしています。
A set of protocols that meet these requirements will require the IANA to make assignments. This document in itself, however, does not require any IANA involvement.
これらの要件を満たす一連のプロトコルでは、IANAが割り当てを行う必要があります。ただし、このドキュメント自体は、IANAの関与を必要としません。
The authors wish to thank Isabel Amonou, Torsten Jaekel, Pierre Loyer, Luoma Juha-Pekka, and Rod Walsh for their detailed inputs. We also wish to acknowledge the input provided by the members of the IETF ipdvb WG.
著者は、Isabel Amonou、Torsten Jaekel、Pierre Loyer、Luoma Juha-Pekka、Rod Walshの詳細な入力に感謝したいと考えています。また、IETF IPDVB WGのメンバーが提供する入力を認めたいと思います。
[ISO-MPEG] ISO/IEC DIS 13818-1:2000, "Information Technology; Generic Coding of Moving Pictures and Associated Audio Information Systems", International Standards Organisation (ISO).
[ISO-MPEG] ISO/IEC DIS 13818-1：2000、「情報技術、移動する写真と関連するオーディオ情報システムの一般的なコーディング」、国際標準組織（ISO）。
[ETSI-DAT] EN 301 192, "Digital Video Broadcasting (DVB); DVB Specifications for Data Broadcasting", European Telecommunications Standards Institute (ETSI).
[ETSI-DAT] EN 301 192、「デジタルビデオブロードキャスト（DVB）;データ放送のためのDVB仕様」、欧州通信標準研究所（ETSI）。
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC] A/53C、「ATSC Digital Television Standard」、Advanced Television Systems Committee（ATSC）、Doc。A/53C、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-A92] A/92, "Delivery of IP Multicast Sessions over ATSC Data Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92, 2002.
[ATSC-A92] A/92、「ATSCデータブロードキャストを介したIPマルチキャストセッションの配信」、Advanced Television Systems Committee（ATSC）、Doc。A/92、2002。
[ATSC-G] A/54A, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A, 2003.
[ATSC-G] A/54A、「ATSCデジタルテレビ標準の使用ガイド」、Advanced Television Systems Committee（ATSC）、Doc。A/54A、2003年。
[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-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。
[CLC99] Clausen, H., Linder, H., and Collini-Nocker, B., "Internet over Broadcast Satellites", IEEE Commun. Mag. 1999, pp.146-151.
[CLC99] Clausen、H.、Linder、H。、およびCollini-Nocker、B。、「インターネットオーバーブロードキャスト衛星」、IEEE Commun。雑誌。1999、pp.146-151。
[ETSI-BSM] TS 102 292, "Satellite Earth Stations and Systems (SES); Broadband Satellite Multimedia Services and Architectures; Functional Architecture for IP Interworking with BSM networks", European Telecommunications Standards Institute (ETSI).
[ETSI-BSM] TS 102 292、「衛星アースステーションおよびシステム（SES）、ブロードバンド衛星マルチメディアサービスとアーキテクチャ、BSMネットワークとのIP IPインターワーキングのための機能アーキテクチャ」、欧州通信標準研究所（ETSI）。
[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV)", European Telecommunications Standards Institute (ETSI).
[ETSI-DVBC] EN 300 800、「デジタルビデオ放送（DVB）;ケーブルテレビ配信システム（CATV）のDVB相互作用チャネル」、欧州通信標準研究所（ETSI）。
[ETSI-DVBRCS] EN 301 790, "Digital Video Broadcasting (DVB); Interaction channel for satellite distribution systems", European Telecommunications Standards Institute (ETSI).
[ETSI-DVBRCS] EN 301 790、「デジタルビデオブロードキャスト（DVB）、衛星配信システム用の相互作用チャネル」、欧州通信標準研究所（ETSI）。
[ETSI-DVBS] EN 301 421,"Digital Video Broadcasting (DVB); Modulation and Coding for DBS satellite systems at 11/12 GHz", European Telecommunications Standards Institute (ETSI).
[ETSI-DVBS] EN 301 421、「デジタルビデオ放送（DVB）; 11/12 GHzでのDBS衛星システムの変調とコーディング」、欧州通信標準研究所（ETSI）。
[ETSI-DVBS2] EN 302 207, "Second generation framing structure, channel coding and modulation systems for Broadcasting, Interactive Services,News Gathering and Other Broadband Satellite Applications", European Telecommunications Standards Institute (ETSI).
[ETSI-DVBS2] EN 302 207、「放送のための第2世代のフレーミング構造、チャネルコーディングおよび変調システム、インタラクティブサービス、ニュース収集、その他のブロードバンド衛星アプリケーション」、欧州通信標準研究所（ETSI）。
[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).
[ETSI-DVBT] EN 300 744、「デジタルビデオブロードキャスト（DVB）;デジタル地上テレビ（DVB-T）のフレーミング構造、チャネルコーディング、変調」、欧州通信標準研究所（ETSI）。
[ETSI-IPDC] "IP Datacast Specification", DVB Interim Specification CNMS 1026 v1.0.0,(Work in Progress), April 2004.
[ETSI-IPDC]「IPデータキャスト仕様」、DVB暫定仕様CNMS 1026 V1.0.0、（進行中の作業）、2004年4月。
[ETSI-MHP] TS 101 812, "Digital Video Broadcasting (DVB); Multimedia Home Platform (MHP) Specification", v1.2.1, European Telecommunications Standards Institute (ETSI), June 2002.
[ETSI-MHP] TS 101 812、「デジタルビデオ放送（DVB）;マルチメディアホームプラットフォーム（MHP）仕様」、v1.2.1、欧州通信標準研究所（ETSI）、2002年6月。
[ETSI-RC] ETS 300 802, "Digital Video Broadcasting (DVB); Network-independent protocols for DVB interactive services", European Telecommunications Standards Institute (ETSI).
[ETSI-RC] ETS 300 802、 "Digital Video Broadcasting（DVB）; DVB Interactive Servicesのネットワーク非依存プロトコル"、欧州通信標準研究所（ETSI）。
[ETSI-SI] EN 300 468, "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems", European Telecommunications Standards Institute (ETSI).
[ETSI-SI] EN 300 468、「デジタルビデオ放送（DVB）; DVBシステムのサービス情報の仕様（SI）、欧州通信基準研究所（ETSI）。
[IPDVB-ULE] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for transmission of IP datagrams over an MPEG-2 Transport Stream", Work in Progress, June 2005.
[IPDVB-ule] Fairhurst、G。およびB. Collini-Nocker、「MPEG-2輸送ストリーム上のIPデータグラムの送信のための単方向の軽量カプセル化（ULE）」、2005年6月、進行中の作業。
[IPDVB-AR] Fairhurst, G. and M-J. Montpetit, "Address Resolution for IP datagrams over MPEG-2 networks", Work in Progress, 2005.
[IPDVB-AR]フェアハースト、G。およびM-J。Montpetit、「MPEG-2ネットワークを介したIPデータグラムのアドレス解像度」、2005年の作業。
[ISO-AUD] ISO/IEC 13818-3:1995, "Information technology; Generic coding of moving pictures and associated audio information; Part 3: Audio", International Standards Organisation (ISO).
[ISO-AUD] ISO/IEC 13818-3：1995、「情報技術、動画と関連するオーディオ情報の一般的なコーディング、パート3：オーディオ」、国際標準組織（ISO）。
[ISO-DSMCC] ISO/IEC IS 13818-6, "Information technology; Generic coding of moving pictures and associated audio information; Part 6: Extensions for DSM-CC", International Standards Organisation (ISO).
[ISO-DSMCC] ISO/IECは13818-6です。
[ISO-VID] ISO/IEC DIS 13818-2:1998, "Information technology; Generic coding of moving pictures and associated audio information; Video", International Standards Organisation (ISO).
[ISO-VID] ISO/IEC DIS 13818-2：1998、「情報技術、動画および関連するオーディオ情報の一般的なコーディング、ビデオ」、International Standards Organization（ISO）。
[ITU-AAL5] ITU-T I.363.5, "B-ISDN ATM Adaptation Layer Specification Type AAL5", International Standards Organisation (ISO), 1996.
[ITU-AAL5] ITU-T I.363.5、 "B-ISDN ATM適応層仕様タイプAAL5"、International Standards Organization（ISO）、1996。
[LLC] ISO/IEC 8802.2, "Information technology; Telecommunications and information exchange between systems; Local and metropolitan area networks; Specific requirements; Part 2: Logical Link Control", International Standards Organisation (ISO), 1998.
[LLC] ISO/IEC 8802.2、「情報技術、システム間の電気通信と情報交換、ローカルおよび大都市圏ネットワーク、特定の要件、パート2：論理リンク制御」、国際標準組織（ISO）、1998。
[MMUSIC-IMG] Nomura, Y., Walsh, R., Luoma, J-P., Ott, J., and H. Schulzrinne, "Requirements for Internet Media Guides", Work in Progress, June 2004.
[MMUSIC-IMG] Nomura、Y.、Walsh、R.、Luoma、J-P。、Ott、J。、およびH. Schulzrinne、「Internet Media Guidesの要件」、2004年6月の作業。
[OPEN-CABLE] "Open Cable Application Platform Specification; OCAP 2.0 Profile", OC-SP-OCAP2.0-I01-020419, Cable Labs, April 2002.
[オープンケーブル]「オープンケーブルアプリケーションプラットフォーム仕様、OCAP 2.0プロファイル」、OC-SP-OCAP2.0-I01-020419、ケーブルラボ、2002年4月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365] Meyer、D。、「管理上スコープIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC2375] Hinden、R。およびS. Deering、「IPv6マルチキャストアドレスの割り当て」、RFC 2375、1998年7月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリー（MLD）」、RFC 2710、1999年10月。
[RFC2507] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507] Degermark、M.、Nordgren、B。、およびS. Pink、「IPヘッダー圧縮」、RFC 2507、1999年2月。
[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月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
[RFC3095] Bormann、C.、Burmeister、C.、Degermark、M.、Fukushima、H.、Hannu、H.、Jonsson、L-e。、Hakenberg、R.、Koren、T.、Le、K.、Liu、Z.、Martensson、A.、Miyazaki、A。 Eng、「堅牢なヘッダー圧縮（ROHC）：フレームワークと4つのプロファイル：RTP、UDP、ESP、および非圧縮」、RFC 3095、2001年7月。
[RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 3171, August 2001.
[RFC3171] Albanna、Z.、Almeroth、K.、Meyer、D。、およびM. Schipper、「IPv4マルチキャストアドレス割り当てのIANAガイドライン」、BCP 51、RFC 3171、2001年8月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569] Bhattacharyya、S。、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、2003年7月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004 .
[RFC3819] Karn、P.、Bormann、C.、Fairhurst、G.、Grossman、D.、Ludwig、R.、Mahdavi、J.、Montenegro、G.、Touch、J。、およびL. Wood、「インターネットサブネットワークデザイナー向けのアドバイス」、BCP 89、RFC 3819、2004年7月。
Appendix A: MPEG-2 Encapsulation Mechanisms
付録A：MPEG-2カプセル化メカニズム
Transmitting packet data over an MPEG-2 transmission network requires that individual PDUs (e.g., IPv4, IPv6 packets, or bridged Ethernet Frames) are encapsulated using a convergence protocol. The following encapsulations are currently standardized for MPEG-2 transmission networks:
MPEG-2トランスミッションネットワーク上でパケットデータを送信するには、個々のPDU（例：IPv4、IPv6パケット、またはブリッジ型イーサネットフレーム）が収束プロトコルを使用してカプセル化されることが必要です。現在、次のカプセルはMPEG-2トランスミッションネットワーク用に標準化されています。
(i) Multi-Protocol Encapsulation (MPE).
(i) マルチプロトコルカプセル化（MPE）。
The MPE specification of DVB [ETSI-DAT] uses private Sections for the transport of IP packets and uses encapsulation that is similar to the IEEE LAN/MAN standards [LLC]. Data packets are encapsulated in datagram sections that are compliant with the DSMCC section format for private data. Some Receivers may exploit section processing hardware to perform a first-level filtering of the packets that arrive at the Receiver.
DVB [ETSI-DAT]のMPE仕様は、IPパケットの輸送にプライベートセクションを使用し、IEEE LAN/MAN標準[LLC]に似たカプセル化を使用します。データパケットは、プライベートデータのDSMCCセクション形式に準拠したデータグラムセクションにカプセル化されています。一部の受信機は、セクション処理ハードウェアを活用して、受信機に到着したパケットの第1レベルのフィルタリングを実行する場合があります。
This encapsulation makes use of a MAC-level Network Point of Attachment address. The address format conforms to the ISO/IEEE standards for LAN/MAN [LLC]. The 48-bit MAC address field contains the MAC address of the destination; it is distributed over six 8-bit fields, labelled MAC_address_1 to MAC_address_6. The MAC_address_1 field contains the most significant byte of the MAC address, while MAC_address_6 contains the least significant byte. How many of these bytes are significant is optional and defined by the value of the broadcast descriptor table [ETSI-DAT] sent separately over another MPEG-2 TS within the TS multiplex.
このカプセル化により、添付アドレスのMacレベルのネットワークポイントが使用されます。アドレス形式は、LAN/MAN [LLC]のISO/IEEE標準に準拠しています。48ビットMACアドレスフィールドには、宛先のMACアドレスが含まれています。6つの8ビットフィールドに分布し、mac_address_1にmac_address_6にラベル付けされています。Mac_Address_1フィールドには、MACアドレスの最も重要なバイトが含まれていますが、Mac_Address_6には最も重要なバイトが含まれています。これらのバイトのうち数が重要であり、TSマルチプレックス内の別のMPEG-2 TS上で個別に送信されるブロードキャスト記述子テーブル[ETSI-DAT]の値によって定義されています。
MPE is currently a widely deployed scheme. Due to Investments in existing systems, usage is likely to continue in current and future MPEG-2 Transmission Networks. ATSC provides a scheme similar to MPE [ATSC-DAT] with some small differences.
MPEは現在、広く展開されているスキームです。既存のシステムへの投資により、使用量は現在および将来のMPEG-2送信ネットワークで継続する可能性があります。ATSCは、いくつかの小さな違いを持つMPE [ATSC-DAT]と同様のスキームを提供します。
(ii) Data Piping.
（ii）データ配管。
The Data Piping profile [ETSI-DAT] is a minimum overhead, simple and flexible profile that makes no assumptions concerning the format of the data being sent. In this profile, the Receiver is intended to provide PID filtering, packet reassembly according to [ETSI-SI], error detection, and optional Conditional Access (link encryption).
データ配管プロファイル[ETSI-DAT]は、送信されるデータの形式に関して仮定を行わない最小オーバーヘッド、シンプルで柔軟なプロファイルです。このプロファイルでは、受信機は、[ETSI-SI]、エラー検出、およびオプションの条件付きアクセス（リンク暗号化）に従って、PIDフィルタリング、パケット再組み立てを提供することを目的としています。
The specification allows the user data stream to be unstructured or organized into packets. The specific structure is transparent to the Receiver. It may conform to any protocol, e.g., IP, Ethernet, NFS, FDDI, MPEG-2 PES, etc.
この仕様により、ユーザーデータストリームを非構造化またはパケットに編成できます。特定の構造はレシーバーに対して透明です。あらゆるプロトコル、例えばIP、イーサネット、NFS、FDDI、MPEG-2 PESなどに適合する場合があります。
(iii) Data Streaming.
（iii）データストリーミング。
The data broadcast specification profile [ETSI-DAT] for PES tunnels (Data Streaming) supports unicast and multicast data services that require a stream-oriented delivery of data packets. This encapsulation maps an IP packet into a single PES Packet payload.
PESトンネル（データストリーミング）のデータブロードキャスト仕様プロファイル[ETSI-DAT]は、データパケットのストリーム指向の配信を必要とするユニキャストおよびマルチキャストデータサービスをサポートしています。このカプセル化は、IPパケットを単一のPESパケットペイロードにマッピングします。
Two different types of PES headers can be selected via the stream_id values [ISO-MPEG]. The private_stream_2 value permits the use of the short PES header with limited overhead, while the private_stream_1 value makes available the scrambling control and the timing and clock reference features of the PES layer.
Stream_ID値[ISO-MPEG]を介して2つの異なるタイプのPESヘッダーを選択できます。private_stream_2値は、限られたオーバーヘッドで短いPESヘッダーの使用を許可しますが、private_stream_1値はスクランブルコントロールとPESレイヤーのタイミングおよびクロック参照機能を利用可能にします。
Authors' Addresses
著者のアドレス
Marie J. Montpetit Motorola Connected Home Solutions 45 Hayden Avenue 4th Floor Lexington MA 02130 USA
マリーJ.モンペティットモトローラコネクテッドホームソリューション45ヘイデンアベニュー4階レキシントンMA 02130 USA
EMail: mmontpetit@motorola.com
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
Horst D. Clausen TIC Systems Lawrence, Kansas
Horst D. Clausen Tic Systems Lawrence、Kansas
EMail: h.d.clausen@ieee.org
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.network-research.org
Hilmar Linder Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria
ヒルマー・リンダー科学コンピューティング局ザルツブルク大学ヤコブ・ハリンジャーSTR。2 5020 Salzburg Austria
EMail: hlinder@cosy.sbg.ac.at
Web: http://www.network-research.org
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://ww.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エディター機能の資金は現在、インターネット協会によって提供されています。