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).
著作権（C）インターネット協会（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）と高度テレビジョンシステム委員会（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データグラムのための新たなカプセル化方法を提案し、MPEG-2 TSによって提供される論理チャネルの特性を有するIPパケットを関連付けることはIPv6 / IPv4アドレス解決を実行するプロトコルを提案しています。
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トランスポートストリーム[ISO-MPEG]オーバーIPデータグラムの輸送のためのアーキテクチャを識別する。主焦点は、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）アーキテクチャ、高度テレビジョンシステム委員会（ATSC）システム[ATSC、ATSC-G]、及び他の類似のMPEG-2-ベースの伝送システム。このようなシステムは、典型的には、単方向（シンプレックス）物理およびリンク層の規格を提供し、物理的なメディアの広い範囲（例えば、地上波テレビ[ETSI-DVBT、ATSC-PSIP-TC]、衛星テレビ[ETSI-DVBS、ETSIのために定義されています-DVBS2、ATSC-S]、ケーブル伝送[ETSI-DVBC、ATSC-PSIP-TC、OPEN-CABLE]、およびMPEG-2 [ETSI-MHP]上のデータ伝送。
+-+-+-+-+------+------------+---+--+--+---------+
|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）テーブル。
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）を提供するために使用することができます。マッピング機能は、IPレベルのQoSにTS論理チャネルをマッピングするために、及びIPは、特定のサブネットワーク機能とフローを関連付けるために、IPアドレスにTS論理チャネルを関連付けるために必要とされています。アーキテクチャの重要な特徴は、これらの機能は、他の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.
DSMCC：デジタルストレージメディアコマンドおよびコントロール[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.
カプセル化：TSパケットのストリームとして出力するためのPDUを受信し、（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：媒体アクセスとコントロール。図6（b）宛先アドレス、（b）ソースアドレス、および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]。 DSM-CCテーブルのセクションを形成し、PDUをカプセル化する仕組み。各セクションは、単一のTS論理チャネルを使用してTSパケットの直列に送信されます。
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards Organisation (ISO) [ISO-MPEG].
MPEG-2：標準モーション・ピクチャー・エキスパート・グループ（MPEG）によって指定され、国際標準化機構（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は、ゼロの周知のPID値を使用して送信されます。
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論理チャネルを識別するために使用されたTSパケットが属する[ISO-MPEG]。表セクション、PES、または他のペイロードユニットの一部を構成するTSパケットはすべて同じPID値を運ぶ必要があります。すべて1のPID値はNULL TSパケットは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：プログラムマップテーブル。 TS論理チャネル/プログラム[ISO-MPEG]を含むストリームのセットによって使用される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つの以上のエレメンタリストリームに関連する個人情報（すなわち、[ISO-MPEG]で定義されていない）、または特定のMPEG-2プログラム、または全体TSを識別するために使用されてもよいです。他の標準化団体（例えば、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多重で運ばサービスに関する情報を伝えるために使用されます。また、SIテーブルを参照して4つの具体的に特定テーブル部構築[ISO-MPEG]のいずれかに搬送されます。
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パケットヘッダで運ば単一ビットのフラグ。ゼロのPUSI値は、TSパケットが新しいペイロードユニットの開始を運ばないことを示しています。 1のPUSI値は、TSパケットが新しいペイロードユニットの開始を携帯していることを示しています。 ULEに、PUSIは、1バイトのペイロード・ポインタ（PP）の存在を示すビットを1に設定します。
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：セットトップボックスを。デジタルTVサービスの受信のための民生機器（レシーバー）。
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：トランスポートストリーム[ISO-MPEG]、TSパケットを使用してMPEG-2レベルで伝送方法。それは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論理チャネルを介して送信されるすべてのパケットは、（この値は、特定のTSマルチプレックス内で一意である）同じPID値を運びます。 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多重：この文書では、この用語は、MPEG-2 TS単下位レイヤ接続を介して送信される論理チャネルのセットを定義します。これは、共通の物理リンク（すなわち、指定されたシンボルレート、FEC設定、送信周波数で送信）、または別のプロトコル層（例えば、イーサネット（登録商標）、又はIPオーバーRTP）によって提供されるカプセルであってもよいです。同じTS論理チャネルは、二つの地上波TV送信セルに同一のマルチキャストコンテンツを再配布するために、例えば、（おそらくは異なるPID値に関連付けられた）複数のTS多重にわたって繰り返されてもよいです。
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多重[ISO-MPEG]を介して送信されるデータの固定長188Bユニット。各TSパケットは、TS関連する論理チャネルのセットを同期するために図4（b）ヘッダ、プラスアダプテーションフィールドを含む任意のオーバーヘッド、暗号化の詳細とタイムスタンプ情報を運びます。また、TS_cellと呼ばれています。各TSパケットは、単一のTS論理チャネルに関連付けることがPID値を運びます。
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]。単一TS論理チャネルを使用してTSパケットの直列に送信されSNDUsに、PDUをカプセル化する仕組み。
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）放送TVおよびラジオ配信は放送TVおよびラジオ配信シナリオにおける主要なサービスは、デジタルテレビ及び/又はラジオとその関連データ[MMUSIC-IMG、ETSI-IPDC]です。貢献フィード、放送部：そのようなネットワークは、通常、2つの成分を含みます。貢献は、放送ネットワークのハブに（通常は高品質の）個々のサイトの一般的少数からの通信を提供フィード。貢献に運ばトラフィックは通常、暗号化されているフィード、通常はネットワークのブロードキャスト部分に再送される前に処理されます。放送部分は、ダウンストリームレシーバの一般的に大量に到達するためにハブを中心としたスター型トポロジを使用しています。このようなネットワークは、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サービスは、適切なMPEG-2の制御情報（例えば、DVBおよびATSC SIテーブル）のPIDの割当及び生成を含むブロードキャスト伝送に使用完全なシステム仕様に準拠しなければなりません。
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）データキャストオーバーレイザデータキャストオーバーレイシナリオは、既存のIPベースのインターネットサービスを補完するような一方向マルチキャストなどの追加の接続性を提供するために、MPEG-2の物理及びリンク層を使用します。そのようなネットワークの例は、モバイル無線受信機[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、また戻り方向に用いてもよいです。このようなシステムはまた、通常（共有）リターンリンク容量を管理するための制御プレーン要素を含みます。具体例は、DVBRCSシステム[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.
シナリオ-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は、実際に一次トラフィックとして（デジタルセットトップボックス（STB）によって受信するためのもの）は、MPEG-2ビデオとオーディオを運ぶことに留意されたいです。他のシナリオでは、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伝送ネットワークは、プライベートネットワークに使用されています。これらは、典型的には、レシーバの小さな数を伴い、集中制御の同じレベルを必要としません。例としては、インターネット（シナリオB）内のリンクを形成するために、DVB-可能なルータを接続することを望む企業を含みます。
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論理チャネルとしてここに知られている並列チャネルの数を提供しています。各論理チャネルは一意にMPEG-2 TSパケットのヘッダで運ばれたパケットID（PID）値によって識別されるTS。 PID値は、13ビットのフィールドです。従って、利用可能なチャネルの数は、SIテーブルの送信のために予約されているいくつかの16進数で0から8191、10進数または0x1FFFの範囲です。論理チャネルは、オーディオ[ISO-AUD]、ビデオ[ISO-VID]、IPパケットを運ぶために使用することができる非予約TS [ISO-DSMCC、ETSI-DAT、ATSC-DAT]、またはその他のデータ[ISO-DSMCC、ETSI -DAT、ATSC-DAT]。値8191小数（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論理チャネルは異なっていてもよい（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接続設定のため、またはIPのマッピングをシグナリングのための指定された標準インタフェースは、PIDのに流れていない、または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).
単純な例では、一つ以上のTS論理チャネルがTS多重その結果、MPEG-2マルチプレクサによって処理されます。 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マルチプレクサ（再多重）を供給することができます。再多重化は、いくつかの場所で発生する（およびシナリオAと3.1節のBに共通である）ことができます。一例では、TS論理チャネル（ブロードキャスト/マルチキャストの場合またはそれ以上）のいずれかに一つ以上の上りリンク物理ベアラ（TS多重）から受信した多重化、ダウンリンク物理TSパケットのオンボード処理を提供する衛星でありますベアラ（TS多重）。再多重化プロセスの一部として、remultiplexor入力が異なる入力多重に担持された同一のPIDを有する論理チャネルをTSとの間の衝突を防止するために、1つ以上のTS論理チャネルに関連付けられたPID値を付け直すことができます。また、変更および/または制御プレーンに新しい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
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トランスポート多重を介して送信するパケットデータは、時々、エンカプスレータに渡されるゲートウェイとして知られています。これは、プロトコルデータユニット、カプセル化ヘッダとトレーラ（セクション4を参照）を添加することにより、イーサネットフレームまたはIPパケット、およびサブネットワークデータユニット、SNDU、フォーマットに各としてPDUを受信します。 SNDUsは、その後、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 SNDUsを搬送する論理チャネルの数に共通です。従って、受信機は、（受け入れる）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論理チャネルをフィルタリングしなければなりません。つのIPフローのためのパケット（つまり、IP送信元および宛先アドレスの特定の組み合わせ）が同じPIDを使用して送信されなければなりません。すべての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経路は、（セクション3.1のシナリオB-Dで例えば、）非MPEG-2リターンリンクを使用してサポートされてもよいです。そのようなアプリケーションの一例は、単方向リンクルーティング、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ブロードキャストパケットを、IPネットワーク内の全てのエンドシステムに送信されました
(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)
（VIII）他のネットワーク・プロトコル・パケット（MPLS、潜在的な新しいプロトコル）
The architecture will provide:
アーキテクチャが提供されます：
(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）の基準を容易エンカプスレータ、又は受信機で実装することができる効率的かつ柔軟なカプセル化スキームを提供します。ペイロードのカプセル化は、パケットの種類および特定のPIDに使用されるカプセルシグナリングする機構を示すためにSNDUの型のフィールドを必要とします。
(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.
（ⅲ）規格またはMACアドレスではないかもしれない可能性アタッチメントのネットワークポイント（NPA）で、特定のIPアドレスを関連付けます。このプロセスは、IPv4アドレス解決プロトコル、ARP、またはIPv6近隣探索、ND、プロトコル[IPDVB-AR]を似ています。また、標準では、IPv6自動設定と互換性があります。
(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）規格は、一つ以上の特定TS論理チャネル（PID、TS多重）とMPEG-2 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）の規格をIPフローとMPEG-2 TS論理チャネルの機能を関連付けること。これは、基礎となるMPEG-2 TSのQoS、マルチホーミングおよび移動するために、IPのQoS / DSCPおよびRSVPなどの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の使用を許可し、明確に指定されたプロトコルに関するセキュリティ上の問題を特定しなければなりません。一方向の転送（通信は受信IPエンドホストに送信するIPエンドホストからのみである）と双方向転送：セキュリティ上の問題は2例を検討する必要があります。クローズドユーザーグループの必要性およびMPEG-2 TSの暗号化の使用：検討も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）IP伝送の管理を、標準化されたSNMPのMIBとエラー報告手順を含みます。これのための必要性と範囲が決定されます。
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パケットまたはイーサネットフレーム）を受信し、サブネットワークデータユニット、SNDUsにこれらをフォーマットとして知られているネットワークデバイス。カプセル化（または収斂）プロトコルは、MPEG-2 TSサービスにわたる各SNDUを搬送し、受信IPインタフェースにカプセル化されたPDUを配信するための適切なメカニズムを提供します。
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）を運びます。いくつかのプロトコルはまた、トレーラ（図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ファミリーは、現在、IPパケットを搬送するための機構、またはマルチプロトコルカプセル化（MPE）[ETSI-DAT]を使用して、イーサネットフレームを定義します。同等の方式は、ATSC [ATSC-DAT、ATSC-DATG]でサポートされています。これは、表セクション内にカプセル化してIPパケットの送信又は（LLCを使用して）イーサネットフレームを可能にする（MPEG-2伝送に関連する制御プレーンで使用される形式を有します）。 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は "payload_unit_start_indicator" と新しいTSパケット内のペイロード・ユニット（PU）の開始を示す（PUSI）[ISO-MPEG] 4B TSパケットヘッダで運ば。 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値は、TSパケットペイロードは、PESパケットの最初のバイトから始まる示します。 「0」の値は、PESパケットがTSパケットで開始しないことを示しています。 PUSIが「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'.
それは、パケットが伝送中に破損または紛失されたTSがない限り、このPUSIビットを使用して、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.
カプセル化は、同じTSパケットに複数のSNDUの梱包を可能にしなければならないし、TSパケットで送信できるSNDUsの数を制限するべきではありません。また、それは不完全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コンバージェンスプロトコルがパックSNDUsの正確な描写を受信することを可能にします。 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.
二つ以上のペイロードユニットの部分は同一の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サイズのSNDUsをサポートしなければなりません。 IPv4およびIPv6パケットフォーマットが64 KBにサイズアップのIPパケットを許可するが、このようなパケットは、ほとんど現在のインターネット上で見られません。高速リンクは、多くの場合、ルータのパケット転送速度によって制限されているので、MTU 1500バイトを超える値をサポートするには、インターネットコアルータのための傾向がありました。 16キロバイトの値は、現在のインターネットのコアでは珍しいことではありません。これは、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の規格で、例えば（このための「セレクタ」の概念を使用しています。この場合には、SNAP（サブネットワークアクセスプロトコル）ヘッダもIPパケットのために必要であるが。
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アドレスは、媒体アクセス制御、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アドレス）のいずれかを介して達成することができます。両方のアドレスが使用される場合、それらは、静的または動的な方法（例えば、アドレス解決処理によって）のいずれかにマッピングされなければなりません。同様の要件は、サービスが実施された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の使用が必要とされる場合もある（例えば、システムがルータとして動作する場合）、これはそれを廃棄するプレフィルタとして受信機によって使用することができるカプセル化ヘッダで運ばなければならない存在する場合、および不要なSNDUs。割り当てられたアドレスは、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伝送ネットワーク（例えば、4ビット連続カウンタはMPEG-2 TSパケットヘッダに含まれる）に存在します。
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キロバイトのペイロードで動作するのに十分であり、そしてさらに大きなペイロードのための適切な保護を提供することができます。
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パケットを防ぐために受信機によって使用され得る情報を含む別によって受信されるから1つの範囲のために意図。同様の機能は、重複範囲を持っていないだけでIPパケットが同じTS論理チャネル上で送信されることを確実にすることによって達成することができます。いくつかのケースでは、これは、複数の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
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）を関連付けるメカニズムを提供するシステムのIPアドレスを持つ情報[IPDVB-AR]。多くの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でのVC、ATMでのVCI、または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）AレシーバID（例えば、図6（b）MAC / NPAアドレス）。 （ⅱ）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).
要素は、（ii）および（iii）のMPEG-2伝送ネットワークは、それらが処理TS論理チャネルのPID値を再番号付け（再）マルチプレクサを含む場合に参照解除される必要があります。 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:
第三の要素（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は、（MPEG TS多重、PID、MAC / NPAアドレス）へのIPユニキャストまたはIPv4ブロードキャストアドレスを解決します。これは、受信機は、IP層へのトラフィックを通過させるためにL2フィルターを設定することができます。これは、ユニキャスト、および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は、（MPEG TS多重、PID、MAC / NPAアドレス）にIPマルチキャストアドレスを解決し、ReceiverがIP層に渡すトラフィックを可能L2フィルタを設定することを可能にします。 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は、他の受信、Bにあるアドレスを解決する必要があります。
(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）ハブのホストは、受信機であるアドレスを解決する必要があります。送信者（カプセル化ゲートウェイ）は、ユニキャスト、IPv4サブネットブロードキャスト及びマルチキャストパケットを送信するためのMPEG TS多重、PID、MAC / NPAアドレスを提供するために、ARを使用します。
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）と同じです：レシーバーのホストが違いを知りません。これらのケースでは、決定すべきアドレスがAR（ケース3の後に順方向（ブロードキャスト）に戻ってMPEG-2チャネルをIPパケットを中継するIPパケットを転送すべきハブのデバイスのL2アドレスは、あります）。
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は、まだバックアウトバウンドMPEG-2チャンネルにIPパケットを中継しなければなりません。 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.
ハブに接続されたエンドホストは、レシーバ、端末MAC / NPAアドレスを解決するためにARプロトコルを使用する必要があります。これは、他のレシーバのL2アドレスが通知されるようにハブでARサーバが必要です。
An AR protocol may transmit AR information in three distinct ways:
ARプロトコルは、3つの異なる方法で、AR情報を送信することができます。
(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）（IPv6のNDのように）IPを介して転送アドレス解決プロトコル
There are three distinct cases in which AR may be used:
ARを使用することができる三つの異なるケースがあります。
(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-マルチプレクサおよび再マルチプレクサの使用は、例えば、地上デジタル、衛星テレビは、多重化を放送しました。多くのそのようなシステムは、彼らは（セクション3.1のシナリオAのように）MPEG-2伝送ネットワークを通過するTS論理チャネルに関連付けられたPID値を変更remultiplexorsを用います。
(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）のチューナーの設定（S）。これらのシステムでは、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マルチプレクサ（即ち、例えば、DOCSIS、一部現在のDVB-RCSマルチキャストシステムのために、唯一の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ネットワークの現在の配備では、論理チャネルは、PIDの特定の（周知の）セットを割り当てられたチャネルを使用して送信TS多重化は、通常、テーブルを介して配信される（サービス情報、SI）を介して搬送されるMPEG-2 TSのセットに関する情報。これはもともとのSTBへのオーディオ/ビデオ配信のために設計されました。この設計は、（MPEG-2セクションのフォーマット[ISO-DSMCC]で運ば）SIテーブル情報を処理することにより、制御プレーンへのアクセスを必要とします。スキームは、マルチメディア、テレビ番組に関連した様々な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の情報を提供するための一つの可能な要件は、既存の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.
照会/応答プロトコルが（と同様、またはNDプロトコルのIPv6近隣広告に基づいて）IPレベルで使用することができます。 ARプロトコルは、以前にPID（例えば、構成、またはSIテーブルを使用して通信）合意を使用してMPEG-2 TS論理チャネル上で動作してもよいです。この場合、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ネットワークをサポートすることができます。このケースである場合、他のスコープに漏れる範囲に対処一つからパケットを防ぐために、アドレスが解決された範囲内のコンテキスト（スコープ）を認識することが重要です。
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.
（ⅱ）NPAブロードキャストアドレス（すべて1 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の設計では、認証があるため、簡単に物理的に接続されている[RFC3819]にあるホストを制御することを可能にするほとんどの既存のIPネットワークの有線性質上、で見過ごされています。無線接続では、これが変更された：不正なホストが実際に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).
（ⅱ）メカニズムは、サーバ（迷惑登録）での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）（IPネットワークリナンバリングなどの後に）クライアントのAR情報を削除する機能。
(v) Support of IP subnetwork scoping.
IPサブネットワークスコーピングの（v）をサポート。
(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伝送ネットワークの上の[RFC1112]をIPv4およびIPv6マルチキャストに関する特定の問題に対処します。マルチキャストサポートの主な目的は、効率的な受信機によって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を使用して構成または設定することができる、等の受信機は、通常、IPv4またはMLDのためのIPグループ管理プロトコル（IGMP [RFC3376]、[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は、通常、マッピング関数ではなく、プロトコルを使用して一対一の関連です。イーサネットでは、送信者は、L2 MACアドレスにIPアドレスをマッピングし、受信機は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）エンカプスレータゲートウェイにIP ARテーブルを移入（すなわち、L2のPIDにマップIP L3のMCAST基）
L2) Distribute the AR information to Receivers
L2）レシーバにAR情報を配布
L2) Set Receiver L2 multicast filters for IP groups in the membership table.
メンバーシップ・テーブル内のIPグループのためのL2）設定レシーバ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属性。個々の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.
ユニキャストの場合と同様に、1つからパケットを防ぐために、マルチキャスト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]。これらのアドレスの転送は、アドレスに関連付けられている範囲によって制御されています。アドレスは、アドレス指定された領域（例えば8分の239 [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マルチキャストアドレスのセットを表示することができ、いくつかのプライベート・ネットワークに分散場合、予期しない結果を生成することができます。
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サーバ、マルチキャストドメインごとに1つずつ使用する必要があります。
The requirements for supporting multicast include, but are not restricted to:
マルチキャストをサポートするための要件は、それだけに限定されません。
(i) Encapsulating multicast packets for transmission using an MPEG-2 TS.
MPEG-2 TSを用いて送信するためのマルチキャストパケットをカプセル化する（I）。
(ii) Mapping IP multicast groups to the underlying MPEG-2 TS Logical Channel (PID) and the MPEG-2 TS Multiplex.
（ⅱ）基本的なMPEG-2 TS論理チャネル（PID）とMPEG-2 TS多重化へのマッピングIPマルチキャストグループ。
(iii) Providing AR information to allow a Receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex.
（III）ReceiverがMPEG-2 TS多重以内IPマルチキャストフローを見つけることができるようにAR情報を提供します。
(iv) Error Reporting.
（ⅳ）エラー報告。
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トランスポートストリーム（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伝送リンク/ネットワークを使用して送信者と受信者の動的な構成を可能にするMPEG-2アドレス解決（AR）の手順を記載しています。ユニキャストとマルチキャストモードの両方でこれらのサポート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伝送ネットワークは、有線ネットワークを使用していない場合、インターネットトラフィックの搬送のための無線リンクの使用に関連する通常のセキュリティ問題は[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）、;
- 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]であり、それはあまりにも頻繁まったく保障されていないデフォルトの状況、より優れているという原則に基づいて、奨励されるべきです。通常、クライアント - - （ラジオ/放送ネットワークおよび/または共有メディア・インターネットアクセスなど）特に脆弱サブネットのユーザは、多くの場合、最大で、一方のエンドポイントをコントロールの上に持っているため、エンド・ツー・エンドのメカニズムの使用を強制することはできません。
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
トランスポート・ストリームで実行される暗号化は、（同じPIDを持つすべてのTS-パケットのペイロードを暗号化）暗号化/スクランブルをSNDUのすべての部分を、レイヤ2のMAC / NPAアドレスを含みます。 MPEセクションレベルでの暗号化はまた、必要に応じて[ETSI-DAT] PDUデータに加えて、レイヤ2のMAC / NPAアドレスを暗号化してもよいです。それは、その後のセットでPDUをフィルタリングすることができます前に、両方のケースでは、MAC / NPAアドレスの暗号化は、すべて暗号化されたデータを復号化するためにレシーバが必要です
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]).
MAC / NPAは、それが受信したいアドレス。また、このメソッドは、すべてのレシーバは、共通の暗号鍵を共有しなければならないという欠点があります。 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、オープンPGP、S / MIME、IPsec）の補完するために、ブロードキャスト/無線リンクで使用されています。暗号化と鍵の交換方法は、目的とする用途に応じて、大幅に異なります。例えば、アクセスネットワーク事業者が運営するDVB-S / DVB-RCSは、セキュリティ・サービスを顧客（インターネット・サービス・プロバイダ、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へのアクセスネットワークオペレータは、エンドユーザーに）ことを共存させることを理解することが重要です。
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.
著者は、その詳細な入力に対してイザベルAmonou、トルステンJaekel、ピエールLoyer、Luomaユハ・ペッカ、およびロッドウォルシュに感謝したいです。我々はまた、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デジタルテレビジョン規格"、高度テレビジョンシステム委員会（ATSC）、ドク。 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データ放送規格"、高度テレビジョンシステム委員会（ATSC）、ドク。 A / 090、2000。
[ATSC-DATG] A/91, "Recommended Practice: Implementation Guidelines for the ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/91, 2001.
[ATSC-DATG] A / 91、：、高度テレビジョンシステム委員会（ATSC）、ドク "推奨プラクティスATSCデータ放送基準の適用指針"。 / 91、2001。
[ATSC-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）、ドク "ATSCデータ放送上のIPマルチキャストセッションの配達"。 / 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）、ドク "ATSCデジタルテレビ規格の使用ガイド"。 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）、ドク[ATSC-PSIP-TC] A / 65B、 "地上波放送とケーブルのためのプログラムとシステム情報プロトコル"。 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）衛星経由のアプリケーションのコーディング要件"、高度テレビジョンシステム委員会（ATSC）、ドク。 / 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.、リンダー、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インターワーキングのための機能アーキテクチャ」、欧州電気通信標準化機構（ETSI）。
[ETSI-DVBC] EN 300 800, "Digital Video Broadcasting (DVB); DVB interaction channel for Cable TV distribution systems (CATV)", European Telecommunications Standards Institute (ETSI).
300 800 EN [ETSI-DVBC]、 "デジタルビデオ放送（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).
301 421 EN [ETSI-DVBS]、 "デジタルビデオ放送（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、欧州電気通信標準化機構（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、 "デジタルビデオ放送（DVB）; DVB双方向サービスのためのネットワークに依存しないプロトコル"、欧州電気通信標準化機構（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] Fairhurst、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 IS「映画と関連オーディオ情報のジェネリックコーディング、情報技術パート6：DSMCC用拡張機能」、国際標準化機構（ISO）。
[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、 "情報技術、映画と関連オーディオ情報のジェネリックコーディング;ビデオ"、国際標準化機構（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"、国際標準化機構（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.
[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]野村、Y.、ウォルシュ、R.、Luoma、J-P。、オット、J.、およびH. Schulzrinneと、 "インターネットメディアガイドのための要件"、進歩、2004年6月での作業。
[OPEN-CABLE] "Open Cable Application Platform Specification; OCAP 2.0 Profile", OC-SP-OCAP2.0-I01-020419, Cable Labs, April 2002.
[OPEN-CABLE] "オープンケーブルアプリケーションプラットフォーム仕様、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]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]マイヤー、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.デアリング、 "IPv6のマルチキャストアドレスの割り当て"、RFC 2375、1998年7月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "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.ピンク、 "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.、藤井、N.、およびY.チャン、 "単方向リンクのリンク層トンネル機構"、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]ボルマン、C.、Burmeister、C.、Degermark、M.、福島、H.、ハンヌ、H.、ジョンソン、LE。、Hakenberg、R.、コレン、T.、ル、K.、劉、 Z.、Martenssonから、A.、宮崎、A.、Svanbro、K.、Wiebke、T.、吉村、T.、およびH.鄭、「ロバストヘッダ圧縮（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.、マイヤー、D.、およびM.シッパー、 "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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]バッタチャリヤ、S.、 "ソース固有マルチキャスト（SSM）の概要"、RFC 3569、2003年7月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、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]カーン、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、「アドバイスインターネットサブネットワークデザイナー」、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).
（ⅰ）マルチプロトコルカプセル化（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.
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_6にMAC_address_1標識。 MAC_address_6は最下位バイトが含まれていながら、MAC_address_1フィールドは、MACアドレスの最上位バイトが含まれています。どのようにこれらのバイトの多くは重要ではオプションと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).
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.
仕様では、ユーザ・データ・ストリームは、構造化されていないか、パケットに編成することを可能にします。具体的な構造は、Receiverに透明です。それは任意のプロトコルに準拠していてもよい、例えば、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.
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.
PESヘッダの二つの異なるタイプのstream_id値[ISO-MPEG]を介して選択することができます。 private_stream_1の値は、PES層のスクランブル制御とタイミングとクロック参照機能利用できるようにしながら、private_stream_2の値は、限られたオーバーヘッドを有する短いPESヘッダの使用を可能にします。
Authors' Addresses
著者のアドレス
Marie J. Montpetit Motorola Connected Home Solutions 45 Hayden Avenue 4th Floor Lexington MA 02130 USA
マリーJ. Montpetitモトローラ接続されたホームソリューション45ヘイデン・アベニュー4階レキシントンMA 02130 USA
EMail: mmontpetit@motorola.com
メールアドレス：mmontpetit@motorola.com
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK
アバディーン、AB24 3UE英国のエンジニアリング大学のGodred Fairhurst部門
EMail: gorry@erg.abdn.ac.uk Web: http://www.erg.abdn.ac.uk/users/gorry
メールアドレス：gorry@erg.abdn.ac.ukウェブ：http://www.erg.abdn.ac.uk/users/gorry
Horst D. Clausen TIC Systems Lawrence, Kansas
ホルスト・D.クラウゼンTICシステムローレンス、カンザス州
EMail: h.d.clausen@ieee.org
メールアドレス：h.d.clausen@ieee.org
Bernhard Collini-Nocker Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria
ザルツブルクヤコブHaringer筋力の科学計算大学のベルンハルトCollini-Nocker部門。 2 5020ザルツブルクオーストリア
EMail: bnocker@cosy.sbg.ac.at Web: http://www.network-research.org
メールアドレス：ウェブbnocker@cosy.sbg.ac.at：http://www.network-research.org
Hilmar Linder Department of Scientific Computing University of Salzburg Jakob Haringer Str. 2 5020 Salzburg Austria
ザルツブルクヤコブHaringer筋力の科学計算大学のヒルマーリンダー部門。 2 5020ザルツブルクオーストリア
EMail: hlinder@cosy.sbg.ac.at Web: http://www.network-research.org
メールアドレス：hlinder@cosy.sbg.ac.atウェブ：http://www.network-research.org
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。