[要約] RFC 4947は、MPEG-2ネットワーク上のIPデータグラムのアドレス解決メカニズムについての要約です。このRFCの目的は、MPEG-2ネットワーク上でのIP通信の効率と信頼性を向上させるためのアドレス解決手法を提案することです。
Network Working Group G. Fairhurst
Request for Comments: 4947 University of Aberdeen
Category: Informational M.-J. Montpetit
Motorola Connected Home Solutions
July 2007
Address Resolution Mechanisms for 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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR) or Neighbor Discovery (ND). Such address resolution complements the higher-layer resource discovery tools that are used to advertise IP sessions.
このドキュメントでは、IPv4/IPv6アドレスをMPEG-2トランスポートストリーム（TS）と結合/関連付けるプロセスについて説明します。この手順は、アドレス解像度（AR）または近隣発見（ND）として知られています。このようなアドレス解像度は、IPセッションの宣伝に使用される高層リソース発見ツールを補完します。
In MPEG-2 Networks, an IP address must be associated with a Packet ID (PID) value and a specific Transmission Multiplex. This document reviews current methods appropriate to a range of technologies (such as DVB (Digital Video Broadcasting), ATSC (Advanced Television Systems Committee), DOCSIS (Data-Over-Cable Service Interface Specifications), and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol.
MPEG-2ネットワークでは、IPアドレスはパケットID（PID）値と特定の伝送マルチプレックスに関連付けられている必要があります。このドキュメントでは、さまざまなテクノロジー（DVB（デジタルビデオブロードキャスト）、ATSC（高度なテレビシステム委員会）、DocSIS（データオーバーサービスインターフェイス仕様）、バリアントなど）に適した現在の方法をレビューします。また、DHCP、ARP、およびNDプロトコルを含むアドレス管理のためのよく知られたプロトコルとの相互作用についても説明しています。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Bridging and Routing .......................................4
2. Conventions Used in This Document ...............................7
3. Address Resolution Requirements ................................10
3.1. Unicast Support ...........................................12
3.2. Multicast Support .........................................12
4. MPEG-2 Address Resolution ......................................14
4.1. Static Configuration ......................................15
4.1.1. MPEG-2 Cable Networks ..............................15
4.2. MPEG-2 Table-Based Address Resolution .....................16
4.2.1. IP/MAC Notification Table (INT) and Its Usage ......17
4.2.2. Multicast Mapping Table (MMT) and Its Usage ........18
4.2.3. Application Information Table (AIT) and Its Usage ..18
4.2.4. Address Resolution in ATSC .........................19
4.2.5. Comparison of SI/PSI Table Approaches ..............19
4.3. IP-Based Address Resolution for TS Logical Channels .......19
5. Mapping IP Addresses to MAC/NPA Addresses ......................21
5.1. Unidirectional Links Supporting Unidirectional
Connectivity ..............................................22
5.2. Unidirectional Links with Bidirectional Connectivity ......23
5.3. Bidirectional Links .......................................25
5.4. AR Server .................................................26
5.5. DHCP Tuning ...............................................27
5.6. IP Multicast AR ...........................................27
5.6.1. Multicast/Broadcast Addressing for UDLR ............28
6. Link Layer Support .............................................29
6.1. ULE without a Destination MAC/NPA Address (D=1) ...........30
6.2. ULE with a Destination MAC/NPA Address (D=0) ..............31
6.3. MPE without LLC/SNAP Encapsulation ........................31
6.4. MPE with LLC/SNAP Encapsulation ...........................31
6.5. ULE with Bridging Header Extension (D=1) ..................32
6.6. ULE with Bridging Header Extension and NPA Address (D=0) ..32
6.7. MPE with LLC/SNAP & Bridging ..............................33
7. Conclusions ....................................................33
8. Security Considerations ........................................34
9. Acknowledgments ................................................35
10. References ....................................................35
10.1. Normative References .....................................35
10.2. Informative References ...................................36
This document describes the process of binding/associating IPv4/IPv6 addresses with MPEG-2 Transport Streams (TS). This procedure is known as Address Resolution (AR), or Neighbor Discovery (ND). Such address resolution complements the higher layer resource discovery tools that are used to advertise IP sessions. The document reviews current methods appropriate to a range of technologies (DVB, ATSC, DOCSIS, and variants). It also describes the interaction with well-known protocols for address management including DHCP, ARP, and the ND protocol.
このドキュメントでは、IPv4/IPv6アドレスをMPEG-2トランスポートストリーム（TS）と結合/関連付けるプロセスについて説明します。この手順は、アドレス解像度（AR）または近隣発見（ND）として知られています。このようなアドレス解像度は、IPセッションの宣伝に使用される高層リソース発見ツールを補完します。ドキュメントでは、さまざまな技術（DVB、ATSC、DOCSIS、およびバリアント）に適した現在の方法をレビューします。また、DHCP、ARP、およびNDプロトコルを含むアドレス管理のためのよく知られたプロトコルとの相互作用についても説明しています。
The MPEG-2 TS provides a time-division multiplexed (TDM) stream that may contain audio, video, and data information, including encapsulated IP Datagrams [RFC4259], defined in specification ISO/IEC 138181 [ISO-MPEG2]. Each Layer 2 (L2) frame, known as a TS Packet, contains a 4 byte header and a 184 byte payload. Each TS Packet is associated with a single TS Logical Channel, identified by a 13-bit Packet ID (PID) value that is carried in the MPEG-2 TS Packet header.
MPEG-2 TSは、指定ISO/IEC 138181 [ISO-MPEG2]で定義されているカプセル化IPデータグラム[RFC4259]を含む、オーディオ、ビデオ、およびデータ情報を含む時間帯マルチプレックス（TDM）ストリームを提供します。TSパケットとして知られる各レイヤー2（L2）フレームには、4バイトヘッダーと184バイトペイロードが含まれています。各TSパケットは、MPEG-2 TSパケットヘッダーで運ばれる13ビットパケットID（PID）値によって識別される単一のTS論理チャネルに関連付けられています。
The MPEG-2 standard also defines a control plane that may be used to transmit control information to Receivers in the form of System Information (SI) Tables [ETSI-SI], [ETSI-SI1], or Program Specific Information (PSI) Tables.
MPEG-2標準は、システム情報（SI）テーブル[ETSI-SI]、[ETSI-SI1]、またはプログラム固有の情報（PSI）テーブルの形式でコントロール情報を受信機に送信するために使用できるコントロールプレーンも定義します。。
To utilize the MPEG-2 TS as a L2 link supporting IP, a sender must associate an IP address with a particular Transmission Multiplex, and within the multiplex, identify the specific PID to be used. This document calls this mapping an AR function. In some AR schemes, the MPEG-2 TS address space is subdivided into logical contexts known as Platforms [ETSI-DAT]. Each Platform associates an IP service provider with a separate context that shares a common MPEG-2 TS (i.e., uses the same PID value).
MPEG-2 TSをIPをサポートするL2リンクとして利用するには、送信者はIPアドレスを特定の伝送マルチプレックスに関連付け、マルチプレックス内で使用する特定のPIDを特定する必要があります。このドキュメントは、このマッピングをAR関数と呼びます。一部のARスキームでは、MPEG-2 TSアドレス空間は、プラットフォーム[ETSI-DAT]として知られる論理コンテキストに細分されます。各プラットフォームは、IPサービスプロバイダーを、一般的なMPEG-2 TSを共有する個別のコンテキストで関連付けます（つまり、同じPID値を使用します）。
MPEG-2 Receivers may use a Network Point of Attachment (NPA) [RFC4259] to uniquely identify a L2 node within an MPEG-2 transmission network. An example of an NPA is the IEEE Medium Access Control (MAC) address. Where such addresses are used, these must also be signalled by the AR procedure. Finally, address resolution could signal the format of the data being transmitted, for example, the encapsulation, with any L2 encryption method and any compression scheme [RFC4259].
MPEG-2レシーバーは、ネットワークアタッチメントポイント（NPA）[RFC4259]を使用して、MPEG-2送信ネットワーク内のL2ノードを一意に識別できます。NPAの例は、IEEE Medium Access Control（MAC）アドレスです。そのようなアドレスが使用される場合、これらはAR手順によっても通知する必要があります。最後に、アドレス解像度は、任意のL2暗号化方法と圧縮スキーム[RFC4259]を使用して、カプセル化など、送信されるデータの形式を信号することができます。
The numbers of Receivers connected via a single MPEG-2 link may be much larger than found in other common LAN technologies (e.g., Ethernet). This has implications on design/configuration of the address resolution mechanisms. Current routing protocols and some multicast application protocols also do not scale to arbitrarily large numbers of participants. Such networks do not by themselves introduce an appreciable subnetwork round trip delay, however many practical MPEG-2 transmission networks are built using links that may introduce a significant path delay (satellite links, use of dial-up modem return, cellular return, etc.). This higher delay may need to be accommodated by address resolution protocols that use this service.
単一のMPEG-2リンクを介して接続された受信機の数は、他の一般的なLANテクノロジー（イーサネットなど）で見つかったものよりもはるかに大きい場合があります。これは、アドレス解決メカニズムの設計/構成に影響を与えます。現在のルーティングプロトコルと一部のマルチキャストアプリケーションプロトコルは、多数の参加者に任意に拡大しません。このようなネットワークは、それ自体ではかなりのサブネットワークラウンドトリップ遅延を導入しませんが、多くの実用的なMPEG-2伝送ネットワークは、重要なパス遅延（衛星リンク、ダイヤルアップモデムリターンの使用、セルラーリターンなどを導入する可能性のあるリンクを使用して構築されています。）。このより高い遅延は、このサービスを使用するアドレス解像度プロトコルによって対応する必要がある場合があります。
The following two figures illustrate the use of AR for a routed and a bridged subnetwork. Various other combinations of L2 and L3 forwarding may also be used over MPEG-2 links (including Receivers that are IP end hosts and end hosts directly connected to bridged LAN segments).
次の2つの図は、ルーティングされたサブネットワークとブリッジ付きサブネットワークに対するARの使用を示しています。L2およびL3転送の他のさまざまな組み合わせは、MPEG-2リンク（Bridged LANセグメントに直接接続されたIPエンドホストとエンドホストを含むレシーバーを含む）を介して使用できます。
Broadcast Link AR
- - - - - - - - -
| |
\/
1a 2b 2a
+--------+ +--------+
----+ R1 +----------+---+ R2 +----
+--------+ MPEG-2 | +--------+
Link |
| +--------+
+---+ R3 +----
| +--------+
|
| +--------+
+---+ R4 +----
| +--------+
|
|
Figure 1: A routed MPEG-2 link
図1：ルーティングされたMPEG-2リンク
Figure 1 shows a routed MPEG-2 link feeding three downstream routers (R2-R4). AR takes place at the Encapsulator (R1) to identify each Receiver at Layer 2 within the IP subnetwork (R2, etc.).
図1は、3つのダウンストリームルーター（R2-R4）を供給するルーティングされたMPEG-2リンクを示しています。ARは、Encapsulator（R1）で行われ、IPサブネットワーク内のレイヤー2の各レシーバーを識別します（R2など）。
When considering unicast communication from R1 to R2, several L2 addresses are involved:
R1からR2へのユニキャスト通信を検討する場合、いくつかのL2アドレスが関与しています。
1a is the L2 (sending) interface address of R1 on the MPEG-2 link. 2b is the L2 (receiving) interface address of R2 on the MPEG-2 link. 2a is the L2 (sending) interface address of R2 on the next hop link.
1Aは、MPEG-2リンク上のR1のL2（送信）インターフェイスアドレスです。2Bは、MPEG-2リンク上のR2のL2（受信）インターフェイスアドレスです。2Aは、次のホップリンクのR2のL2（送信）インターフェイスアドレスです。
AR for the MPEG-2 link allows R1 to determine the L2 address (2b) corresponding to the next hop Receiver, router R2.
MPEG-2リンクのARを使用すると、R1は次のホップレシーバーであるルーターR2に対応するL2アドレス（2B）を決定できます。
Figure 2 shows a bridged MPEG-2 link feeding three downstream bridges (B2-B4). AR takes place at the Encapsulator (B1) to identify each Receiver at L2 (B2-B4). AR also takes place across the IP subnetwork allowing the Feed router (R1) to identify the downstream Routers at Layer 2 (R2, etc.). The Encapsulator associates a destination MAC/NPA address with each bridged PDU sent on an MPEG-2 link. Two methods are defined by ULE (Unidirectional Lightweight Encapsulation) [RFC4326]:
図2は、3つの下流のブリッジ（B2-B4）を供給するブリッジされたMPEG-2リンクを示しています。ARは、L2（B2-B4）で各受信機を識別するために、エンカプセーター（B1）で行われます。ARはまた、IPサブネットワーク全体で行われ、フィードルーター（R1）がレイヤー2（R2など）の下流ルーターを識別できるようにします。Encapsulatorは、MPEG-2リンクで送信される各ブリッジPDUに宛先MAC/NPAアドレスを関連付けます。2つの方法は、ULE（一方向の軽量カプセル化）[RFC4326]で定義されています。
The simplest method uses the L2 address of the transmitted frame. This is the MAC address corresponding to the destination within the L2 subnetwork (the next hop router, 2b of R2). This requires each Receiver (B2-B4) to associate the receiving MPEG-2 interface with the set of MAC addresses that exist on the L2 subnetworks that it feeds. Similar considerations apply when IP-based tunnels support L2 services (including the use of UDLR (Unidirectional Links) [RFC3077]).
最も単純な方法では、送信されたフレームのL2アドレスを使用します。これは、L2サブネットワーク内の宛先に対応するMACアドレス（次のホップルーター、R2の2B）です。これには、各受信機（B2-B4）が受信MPEG-2インターフェイスを、供給するL2サブネットワークに存在するMACアドレスのセットに関連付ける必要があります。同様の考慮事項は、IPベースのトンネルがL2サービスをサポートする場合に適用されます（UDLR（単方向リンク）[RFC3077]の使用を含む）。
It is also possible for a bridging Encapsulator (B1) to encapsulate a PDU with a link-specific header that also contains the MAC/NPA address associated with a Receiver L2 interface on the MPEG-2 link (Figure 2). In this case, the destination MAC/NPA address of the encapsulated frame is set to the Receiver MAC/NPA address (y), rather than the address of the final L2 destination. At a different level, an AR binding is also required for R1 to associate the destination L2 address 2b with R2. In a subnetwork using bridging, the systems R1 and R2 will normally use standard IETF-defined AR mechanisms (e.g., IPv4 Address Resolution Protocol (ARP) [RFC826] and the IPv6 Neighbor Discovery Protocol (ND) [RFC2461]) edge-to-edge across the IP subnetwork.
また、ブリッジングカプセル（B1）は、MPEG-2リンクのレシーバーL2インターフェイスに関連付けられたMAC/NPAアドレスも含むリンク固有のヘッダーでPDUをカプセル化することも可能です（図2）。この場合、カプセル化されたフレームの宛先MAC/NPAアドレスは、最終的なL2宛先のアドレスではなく、受信機MAC/NPAアドレス（Y）に設定されます。別のレベルでは、R1が宛先L2アドレス2BをR2に関連付けるには、AR結合も必要です。ブリッジングを使用したサブネットワークでは、システムR1とR2は通常、標準のIETF定義ARメカニズム（例えば、IPv4アドレス解像度プロトコル（ARP）[RFC826]およびIPv6隣接ディスカバリープロトコル（ND）[RFC2461]）エッジとエッジを使用します。IPサブネットワーク全体のエッジ。
Subnetwork AR
- - - - - - - - - - - - - - - -
| |
| MPEG-2 Link AR |
- - - - - - - - -
| | | |
\/ \/
1a x y 2b 2a
+--------+ +----+ +----+ +--------+
----+ R1 +--| B1 +----------+---+ B2 +--+ R2 +----
+--------+ +----+ MPEG-2 | +----+ +--------+
Link |
| +----+
+---+ B3 +--
| +----+
|
| +----+
+---+ B4 +--
| +----+
|
Figure 2: A bridged MPEG-2 link
図2：ブリッジ付きMPEG-2リンク
Methods also exist to assign IP addresses to Receivers within a network (e.g., stateless autoconfiguration [RFC2461], DHCP [RFC2131], DHCPv6 [RFC3315], and stateless DHCPv6 [RFC3736]). Receivers may also participate in the remote configuration of the L3 IP addresses used in connected equipment (e.g., using DHCP-Relay [RFC3046]).
ネットワーク内の受信機にIPアドレスを割り当てる方法も存在します（例：Stateless Autoconfiguration [RFC2461]、DHCP [RFC2131]、DHCPV6 [RFC3315]、およびStateless DHCPV6 [RFC3736]）。受信機は、接続された機器で使用されるL3 IPアドレスのリモート構成（DHCP-relay [RFC3046]を使用）に参加することもできます。
The remainder of this document describes current mechanisms and their use to associate an IP address with the corresponding TS Multiplex, PID value, the MAC/NPA address and/or Platform ID. A range of approaches is described, including Layer 2 mechanisms (using MPEG-2 SI tables), and protocols at the IP level (including ARP [RFC826] and ND [RFC2461]). Interactions and dependencies between these mechanisms and the encapsulation methods are described. The document does not propose or define a new protocol, but does provide guidance on issues that would need to be considered to supply IP-based address resolution.
このドキュメントの残りの部分では、現在のメカニズムと、IPアドレスを対応するTSマルチプレックス、PID値、MAC/NPAアドレス、および/またはプラットフォームIDに関連付けるための使用について説明しています。レイヤー2メカニズム（MPEG-2 SIテーブルを使用）、およびIPレベルでのプロトコル（ARP [RFC826]およびND [RFC2461]を含む）など、さまざまなアプローチが説明されています。これらのメカニズムとカプセル化方法との相互作用と依存関係について説明します。このドキュメントは、新しいプロトコルを提案または定義するものではありませんが、IPベースのアドレス解決を提供するために考慮する必要がある問題に関するガイダンスを提供します。
AIT: Application Information Table specified by the Multimedia Home Platform (MHP) specifications [ETSI-MHP]. This table may carry IPv4/IPv6 to MPEG-2 TS address resolution information.
AIT：マルチメディアホームプラットフォーム（MHP）仕様[ETSI-MHP]によって指定されたアプリケーション情報表。このテーブルは、IPv4/IPv6をMPEG-2 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-MPEG2].
ATSC：高度なテレビシステム委員会[ATSC]。ISO MPEG-2標準[ISO-MPEG2]を使用したビデオ、オーディオ、およびデータの送信に関するフレームワークと一連の関連標準。
b: bit. For example, one byte consists of 8-bits.
B：ビット。たとえば、1つのバイトは8ビットで構成されています。
B: Byte. Groups of bytes are represented in Internet byte order.
B：バイト。バイトのグループは、インターネットバイトの順序で表されます。
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for the transmission of data and control information carried in an MPEG-2 Private Section, defined by the ISO MPEG-2 standard.
DSM-CC：デジタルストレージメディアコマンドとコントロール[ISO-DSMCC]。ISO MPEG-2標準で定義されたMPEG-2プライベートセクションにあるデータおよび制御情報の送信のための形式。
DVB: Digital Video Broadcasting [DVB]. 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.
DVB：デジタルビデオ放送[DVB]。ISO MPEG-2標準を使用して、ビデオ、オーディオ、およびデータの送信のために、欧州通信標準研究所（ETSI）が発行した関連する基準のフレームワークとセット。
DVB-RCS: Digital Video Broadcast Return Channel via Satellite. A bidirectional IPv4/IPv6 service employing low-cost Receivers [ETSI-RCS].
DVB-RCS：衛星経由のデジタルビデオブロードキャストリターンチャネル。低コストの受信機[ETSI-RCS]を採用する双方向IPv4/IPv6サービス。
DVB-S: Digital Video Broadcast for Satellite [ETSI-DVBS].
DVB-S：衛星のためのデジタルビデオブロードキャスト[ETSI-DVBS]。
Encapsulator: A network device that receives PDUs and formats these into Payload Units (known here as SNDUs) for output as a stream of TS Packets.
Encapsurator：PDUを受信し、これらをTSパケットのストリームとして出力のペイロードユニット（ここで知られている）にフォーマットするネットワークデバイス。
Feed Router: The router delivering the IP service over a Unidirectional Link.
フィードルーター：IPサービスを単方向リンク上に配信するルーター。
INT: Internet/MAC Notification Table. A unidirectional address resolution mechanism using SI and/or PSI Tables.
INT：インターネット/MAC通知テーブル。SIおよび/またはPSIテーブルを使用した単方向アドレス解像度メカニズム。
L2: Layer 2, the link layer.
L2：レイヤー2、リンクレイヤー。
L3: Layer 3, the IP network layer.
L3：レイヤー3、IPネットワークレイヤー。
MAC: Medium Access Control [IEEE-802.3]. A link layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2).
MAC：中アクセスコントロール[IEEE-802.3]。IEEE 802.3標準（またはイーサネットv2によって定義されたリンクレイヤープロトコル。
MAC Address: A 6-byte link layer address of the format described by the Ethernet IEEE 802 standard (see also NPA).
MACアドレス：イーサネットIEEE 802標準で説明されている形式の6バイトリンクレイヤーアドレス（NPAも参照）。
MAC Header: The link layer header of the IEEE 802.3 standard [IEEE-802.3] or Ethernet v2. It consists of a 6-byte destination address, 6-byte source address, and 2 byte type field (see also NPA, LLC (Logical Link Control)).
Macヘッダー：IEEE 802.3標準[IEEE-802.3]またはイーサネットV2のリンクレイヤーヘッダー。これは、6バイトの宛先アドレス、6バイトのソースアドレス、2バイト型フィールドで構成されています（NPA、LLC（論理リンクコントロール）も参照）。
MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia Receiver, that may (in some cases) support IPv4/IPv6 services [ETSI-MHP].
MHP：マルチメディアホームプラットフォーム。統合されたMPEG-2マルチメディアレシーバーは、（場合によっては）IPv4/IPv6サービス[ETSI-MHP]をサポートする可能性があります。
MMT: Multicast Mapping Table (proprietary extension to DVB-RCS [ETSI-RCS] defining an AR table that maps IPv4 multicast addresses to PID values).
MMT：マルチキャストマッピングテーブル（DVB-RCS [ETSI-RCS]の独自の拡張機能[ETSI-RCS] IPv4マルチキャストアドレスをPID値にマッピングするARテーブルを定義）。
MPE: Multiprotocol Encapsulation [ETSI-DAT], [ATSC-A90]. A method that encapsulates PDUs, forming a DSM-CC Table Section. Each Section is sent in a series of TS Packets using a single Stream (TS Logical Channel).
MPE：マルチプロトコルカプセル化[ETSI-DAT]、[ATSC-A90]。PDUをカプセル化し、DSM-CCテーブルセクションを形成するメソッド。各セクションは、単一のストリーム（TS論理チャネル）を使用して、一連のTSパケットで送信されます。
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards Organization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
MPEG-2：Motion Picture Experts Group（MPEG）によって指定され、国際標準組織（ISO/IEC 113818-1）[ISO-MPEG2]およびITU-T（H.220）によって標準化された一連の標準セット。
NPA: Network Point of Attachment. A 6-byte destination address (resembling an IEEE MAC address) within the MPEG-2 transmission network that is used to identify individual Receivers or groups of Receivers [RFC4259].
NPA：添付ファイルのネットワークポイント。MPEG-2送信ネットワーク内の6バイトの宛先アドレス（IEEE MACアドレスに似ています）は、個々の受信機または受信機のグループを識別するために使用されます[RFC4259]。
PAT: Program Association Table. An MPEG-2 PSI control table. It associates each program with the PID value that is used to send the associated PMT (Program Map Table). The table is sent using the well-known PID value of 0x000, and is required for an MPEG-2 compliant Transport Stream.
PAT：プログラムアソシエーションテーブル。MPEG-2 PSIコントロールテーブル。関連するPMT（プログラムマップテーブル）を送信するために使用されるPID値に各プログラムを関連付けます。このテーブルは、0x000のよく知られているPID値を使用して送信され、MPEG-2準拠の輸送ストリームに必要です。
PDU: Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 Datagrams, and other network packets.
PDU：プロトコルデータユニット。PDUの例には、イーサネットフレーム、IPv4またはIPv6データグラム、その他のネットワークパケットが含まれます。
PID: Packet Identifier [ISO-MPEG2]. A 13 bit field carried in the header of each TS Packet. This identifies the TS Logical Channel to which a TS Packet belongs [ISO-MPEG2]. The TS Packets that form the parts of a Table Section, or other Payload Unit must all carry the same PID value. A PID value of all ones indicates a Null TS Packet introduced to maintain a constant bit rate of a TS Multiplex. There is no required relationship between the PID values used for TS Logical Channels transmitted using different TS Multiplexes.
PID：パケット識別子[ISO-MPEG2]。各TSパケットのヘッダーに13ビットフィールドが運ばれます。これは、TSパケットが属するTS論理チャネルを識別します[ISO-MPEG2]。テーブルセクションの部分を形成するTSパケット、または他のペイロードユニットはすべて同じPID値を持つ必要があります。すべてのPID値は、TSマルチプレックスの一定のビットレートを維持するために導入されたnull TSパケットを示します。異なるTSマルチプレックスを使用して送信されるTS論理チャネルに使用されるPID値の間に必要な関係はありません。
PMT: Program Map Table. An MPEG-2 PSI control table that associates the PID values used by the set of TS Logical Channels/ Streams that comprise a program [ISO-MPEG2]. The PID value used to send the PMT for a specific program is defined by an entry in the PAT.
PMT：プログラムマップテーブル。プログラム[ISO-MPEG2]を構成するTS論理チャネル/ストリームのセットで使用されるPID値を関連付けるMPEG-2 PSI制御テーブル。特定のプログラムにPMTを送信するために使用されるPID値は、PATのエントリによって定義されます。
Private Section: A syntactic structure constructed according to Table 2-30 of [ISO-MPEG2]. The structure may be used to identify private information (i.e., not defined by [ISO-MPEG2]) relating to one or more elementary streams, or a specific MPEG-2 program, or the entire Transport Stream. Other Standards bodies, e.g., ETSI and ATSC, have defined sets of table structures using the private_section structure. A Private Section is transmitted as a sequence of TS Packets using a TS Logical Channel. A TS Logical Channel may carry sections from more than one set of tables.
プライベートセクション：[ISO-MPEG2]の表2-30に従って構築された構文構造。構造は、1つ以上の基本的なストリーム、特定のMPEG-2プログラム、または輸送ストリーム全体に関連する個人情報（つまり、[ISO-MPEG2]で定義されていない）を識別するために使用できます。ETSIやATSCなど、その他の標準団体は、private_section構造を使用してテーブル構造のセットを定義しています。プライベートセクションは、TS論理チャネルを使用してTSパケットのシーケンスとして送信されます。TS論理チャネルには、複数のテーブルセットからセクションを搭載する場合があります。
PSI: Program Specific Information [ISO-MPEG2]. 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-MPEG2], see also SI Table.
PSI：プログラム固有の情報[ISO-MPEG2]。PSIは、TSマルチプレックスで運ばれるサービスに関する情報を伝えるために使用されます。特別に識別された4つのテーブルセクションコンストラクト[ISO-MPEG2]のいずれかに掲載されています。SIテーブルも参照してください。
Receiver: Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer).
受信機：TSマルチプレックスから信号を処理し、カプセル化されたPDUのフィルタリングと転送をネットワーク層サービス（またはリンクレイヤーで操作するときにモジュールをブリッジ）します。
SI Table: Service Information Table [ISO-MPEG2]. In this document, this term describes a table that is been defined by another standards body to convey information about the services carried in a TS Multiplex. A Table may consist of one or more Table Sections, however, all sections of a particular SI Table must be carried over a single TS Logical Channel [ISO-MPEG2].
SIテーブル：サービス情報テーブル[ISO-MPEG2]。このドキュメントでは、この用語では、TSマルチプレックスで運ばれるサービスに関する情報を伝えるために別の標準団体によって定義されたテーブルについて説明しています。テーブルは1つ以上のテーブルセクションで構成されている場合がありますが、特定のSIテーブルのすべてのセクションは、単一のTS論理チャネル[ISO-MPEG2]に携帯する必要があります。
SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU：サブネットワークデータユニット。MPEG-2ペイロードユニットとして送信されたカプセル化されたPDU。
Table Section: A Payload Unit carrying all or a part of an SI or PSI Table [ISO-MPEG2].
表セクション：SIまたはPSIテーブルの全部または一部を運ぶペイロードユニット[ISO-MPEG2]。
TS: Transport Stream [ISO-MPEG2], a method of transmission at the MPEG-2 level using TS Packets; it represents Layer 2 of the ISO/OSI reference model. See also TS Logical Channel and TS Multiplex.
TS：TSパケットを使用したMPEG-2レベルでの伝送方法であるTransport Stream [ISO-MPEG2]。ISO/OSI参照モデルのレイヤー2を表します。TS論理チャネルとTSマルチプレックスも参照してください。
TS Logical Channel: Transport Stream Logical Channel. In this document, this term identifies a channel at the MPEG-2 level [ISO-MPEG2]. This exists at level 2 of the ISO/OSI reference model. All packets sent over a TS Logical Channel carry the same PID value (this value is unique within a specific TS Multiplex). The term "Stream" is defined in MPEG-2 [ISO-MPEG2]. This describes the content carried by a specific TS Logical Channel (see ULE Stream). Some PID values are reserved (by MPEG-2) for specific signaling. Other standards (e.g., ATSC and DVB) also reserve specific PID values.
TS論理チャネル：輸送ストリーム論理チャネル。このドキュメントでは、この用語はMPEG-2レベル[ISO-MPEG2]でチャネルを識別します。これは、ISO/OSI参照モデルのレベル2に存在します。TS論理チャネルを介して送信されるすべてのパケットは、同じPID値を持ちます（この値は特定のTSマルチプレックス内で一意です）。「ストリーム」という用語は、MPEG-2 [ISO-MPEG2]で定義されています。これは、特定のTS論理チャネルによって運ばれるコンテンツを説明します（ULEストリームを参照）。一部のPID値は、特定のシグナル伝達のために（MPEG-2によって）予約されています。他の標準（ATSCやDVBなど）も特定のPID値を予約しています。
TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower layer connection. This may be a common physical link (i.e., a transmission at a specified symbol rate, FEC setting, and transmission frequency) or an encapsulation provided by another protocol layer (e.g., Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly associated with a different PID value) [RFC4259], for example, to redistribute the same multicast content to two terrestrial TV transmission cells.
TS Multiplex：このドキュメントでは、この用語は、単一の下層接続で送信されるMPEG-2 TS論理チャネルのセットを定義します。これは、一般的な物理リンク（つまり、指定されたシンボルレート、FEC設定、および伝送周波数での伝送）または別のプロトコル層（例：イーサネット、またはIP経由のRTP）によって提供されるカプセル化です。同じTS論理チャネルは、複数のTSマルチプレックス（おそらく異なるPID値に関連付けられている可能性がある）[RFC4259]、たとえば、同じマルチキャストコンテンツを2つの陸生テレビ伝送セルに再分配することができます。
TS Packet: A fixed-length 188B unit of data sent over a TS Multiplex [ISO-MPEG2]. Each TS Packet carries a 4B header.
TSパケット：TSマルチプレックス[ISO-MPEG2]を介して送信されたデータの固定長18B単位。各TSパケットには4Bヘッダーが搭載されています。
UDL: Unidirectional link: A one-way transmission link. For example, and IP over DVB link using a broadcast satellite link.
UDL：単方向リンク：一元配置伝送リンク。たとえば、ブロードキャスト衛星リンクを使用したDVB上のリンクを使用します。
ULE: Unidirectional Lightweight Encapsulation. A scheme that encapsulates PDUs, into SNDUs that are sent in a series of TS Packets using a single TS Logical Channel [RFC4326].
ule：単方向の軽量カプセル化。PDUをカプセル化するスキームは、単一のTS論理チャネル[RFC4326]を使用して、一連のTSパケットで送信されるSNDUSに送信されます。
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [RFC4326, ISO-MPEG2].
ULEストリーム：ULEカプセル化されたPDUのみを搭載したMPEG-2 TS論理チャネル。ULEストリームは、SI/PSI [RFC4326、ISO-MPEG2]のStream_Typeの定義により識別できます。
The MPEG IP address resolution process is independent of the choice of encapsulation and needs to support a set of IP over MPEG-2 encapsulation formats, including Multi-Protocol Encapsulation (MPE) ([ETSI-DAT], [ATSC-A90]) and the IETF-defined Unidirectional Lightweight Encapsulation (ULE) [RFC4326].
MPEG IPアドレス解像度プロセスは、カプセル化の選択とは無関係であり、マルチプロトコルカプセル化（MPE）（[ETSI-DAT]、[ATSC-A90]）、およびMPEG-2カプセル化形式のセットをサポートする必要があります。IETF定義された単方向の軽量カプセル化（ULE）[RFC4326]。
The general IP over MPEG-2 AR requirements are summarized below:
MPEG-2 AR要件に関する一般的なIPを以下にまとめます。
- A scalable architecture that may support large numbers of systems within the MPEG-2 Network [RFC4259].
- MPEG-2ネットワーク内の多数のシステムをサポートできるスケーラブルなアーキテクチャ[RFC4259]。
- A protocol version, to indicate the specific AR protocol in use and which may include the supported encapsulation method.
- 使用中の特定のARプロトコルを示すプロトコルバージョンと、サポートされているカプセル化方法を含む場合があります。
- A method (e.g., well-known L2/L3 address/addresses) to identify the AR Server sourcing the AR information.
- AR情報を調達するARサーバーを識別する方法（よく知られているL2/L3アドレス/アドレス）。
- A method to represent IPv4/IPv6 AR information (including security mechanisms to authenticate the AR information to protect against address masquerading [RFC3756]).
- IPv4/IPv6 AR情報を表す方法（AR情報を認証するためのセキュリティメカニズムを含む、住所の仮定[RFC3756]から保護するためのAR情報を認証します）。
- A method to install AR information associated with clients at the AR Server (registration).
- ARサーバーのクライアントに関連付けられたAR情報をインストールする方法（登録）。
- A method for transmission of AR information from an AR Server to clients that minimize the transmission cost (link-local multicast is preferable to subnet broadcast).
- AR情報をARサーバーからクライアントに送信する方法は、送信コストを最小限に抑える方法です（Link-Local Multicastは、サブネットブロードキャストよりも望ましいです）。
- Incremental update of the AR information held by clients.
- クライアントが保有するAR情報の増分更新。
- Procedures for purging clients of stale AR information.
- 古いARの情報のクライアントをパージする手順。
An MPEG-2 transmission network may support multiple IP networks. If this is the case, it is important to recognize the scope within which an address is resolved to prevent packets from one addressed scope leaking into other scopes [RFC4259]. Examples of overlapping IP address assignments include:
MPEG-2トランスミッションネットワークは、複数のIPネットワークをサポートする場合があります。この場合、他のスコープに漏れたアドレス指定されたスコープからパケットを防ぐためにアドレスが解決される範囲を認識することが重要です[RFC4259]。重複するIPアドレスの割り当ての例は次のとおりです。
(i) Private unicast addresses (e.g., in IPv4, 10/8 prefix; 172.16/12 prefix; and 192.168/16 prefix). Packets with these addresses should be confined to one addressed area. IPv6 also defines link-local addresses that must not be forwarded beyond the link on which they were first sent.
(i) プライベートユニキャストアドレス（例：IPv4、10/8プレフィックス、172.16/12プレフィックス、192.168/16プレフィックス）。これらのアドレスを含むパケットは、1つのアドレス指定された領域に限定する必要があります。IPv6は、最初に送信されたリンクを超えて転送してはならないリンクローカルアドレスも定義します。
(ii) 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].
（ii）ローカルスコープマルチキャストアドレス。これらはローカルエリア内でのみ有効です（IPv4の例には、224.0.0/24; 224.0.1/24）。一部のIPv6マルチキャストアドレス[RFC2375]についても同様のケースが存在します。
(iii) Scoped multicast addresses [RFC2365] and [RFC2375]. Forwarding of these addresses is controlled by the scope associated with the address. The addresses are only valid within an addressed area (e.g., the 239/8 [RFC2365]).
（iii）スコープマルチキャストアドレス[RFC2365]および[RFC2375]。これらのアドレスの転送は、アドレスに関連付けられたスコープによって制御されます。アドレスは、アドレス指定された領域内でのみ有効です（例：239/8 [RFC2365]）。
Overlapping address assignments may also occur at L2, where the same MAC/NPA address is used to identify multiple Receivers [RFC4259]:
オーバーラップアドレスの割り当てもL2で発生する場合があります。このMAC/NPAアドレスを使用して、複数の受信機[RFC4259]を識別するために使用されます。
(i) An MAC/NPA unicast address must be unique within the addressed area. The IEEE-assigned MAC addresses used in Ethernet LANs are globally unique. If the addresses are not globally unique, an address must only be re-used by Receivers in different addressed (scoped) areas.
(i) MAC/NPAユニキャストアドレスは、アドレス指定された領域内で一意でなければなりません。イーサネットLANで使用されるIEEEに割り当てられたMacアドレスは、グローバルにユニークです。アドレスがグローバルに一意でない場合、アドレスは、異なるアドレス（スコープ）領域の受信機のみが再利用する必要があります。
(ii) The MAC/NPA address broadcast address (a L2 address of all ones). Traffic with this address should be confined to one addressed area.
（ii）MAC/NPAアドレス放送アドレス（すべてのL2アドレス）。このアドレスを使用したトラフィックは、1つのアドレス指定された領域に限定する必要があります。
(iii) IP and other protocols may view sets of L3 multicast addresses as link-local. This may produce unexpected results if frames with the corresponding multicast L2 addresses are distributed to systems in a different L3 network or multicast scope (Sections 3.2 and 5.6).
（iii）IPおよびその他のプロトコルは、L3マルチキャストアドレスのセットをLink-Localと見なす場合があります。これにより、対応するマルチキャストL2アドレスを持つフレームが異なるL3ネットワークまたはマルチキャストスコープのシステムに配布される場合、これは予期しない結果をもたらす可能性があります（セクション3.2および5.6）。
Reception of unicast packets destined for another addressed area will lead to an increase in the rate of received packets by systems connected via the network. Reception of the additional network traffic may contribute to processing load, but should not lead to unexpected protocol behaviour, providing that systems can be uniquely addressed at L2. It does however introduce a potential Denial of Service (DoS) opportunity. When the Receiver operates as an IP router, the receipt of such a packet can lead to unexpected protocol behaviour.
別のアドレス指定されたエリアに向けられたユニキャストパケットの受信は、ネットワークを介して接続されたシステムによって受信されたパケットのレートの増加につながります。追加のネットワークトラフィックの受信は、処理負荷に寄与する可能性がありますが、予期しないプロトコル動作につながるべきではありません。これは、システムにL2で一意に対処できることを提供します。ただし、潜在的なサービス拒否（DOS）の機会を導入します。受信機がIPルーターとして動作する場合、そのようなパケットの受領は予期しないプロトコル動作につながる可能性があります。
Unicast address resolution is required at two levels.
ユニキャストアドレス解像度は2つのレベルで必要です。
At the lower level, the IP (or MAC) address needs to be associated with a specific TS Logical Channel (PID value) and the corresponding TS Multiplex (Section 4). Each Encapsulator within an MPEG-2 Network is associated with a set of unique TS Logical Channels (PID values) that it sources [ETSI-DAT, RFC4259]. Within a specific scope, the same unicast IP address may therefore be associated with more than one Stream, and each Stream contributes different content (e.g., when several different IP Encapsulators contribute IP flows destined to the same Receiver). MPEG-2 Networks may also replicate IP packets to send the same content (Simulcast) to different Receivers or via different TS Multiplexes. The configuration of the MPEG-2 Network must prevent a Receiver accepting duplicated copies of the same IP packet.
低いレベルでは、IP（またはMAC）アドレスを特定のTS論理チャネル（PID値）と対応するTSマルチプレックス（セクション4）に関連付ける必要があります。MPEG-2ネットワーク内の各カプセル装置は、[ETSI-DAT、RFC4259]をソースする一意のTS論理チャネル（PID値）のセットに関連付けられています。したがって、特定の範囲内で、同じユニキャストIPアドレスが複数のストリームに関連付けられている可能性があり、各ストリームは異なるコンテンツに寄与します（たとえば、いくつかの異なるIPカプセルが同じレシーバーに運命づけられたIPフローに寄与する場合）。MPEG-2ネットワークは、IPパケットを複製して、同じコンテンツ（Simulcast）を異なる受信機または異なるTSマルチプレックスを介して送信することもできます。MPEG-2ネットワークの構成は、同じIPパケットの重複したコピーを受け入れるレシーバーを防ぐ必要があります。
At the upper level, the AR procedure needs to associate an IP address with a specific MAC/NPA address (Section 5).
上位レベルでは、AR手順では、IPアドレスを特定のMAC/NPAアドレスに関連付ける必要があります（セクション5）。
Multicast is an important application for MPEG-2 transmission networks, since it exploits the advantages of native support for link broadcast. Multicast address resolution occurs at the network-level in associating a specific L2 address with an IP Group Destination Address (Section 5.6). In IPv4 and IPv6 over Ethernet, this association is normally a direct mapping, and this is the default method also specified in both ULE [RFC4326] and MPE [ETSI-DAT].
マルチキャストは、MPEG-2トランスミッションネットワークにとって重要なアプリケーションです。これは、リンクブロードキャストのネイティブサポートの利点を活用するためです。マルチキャストアドレス解像度は、特定のL2アドレスをIPグループの宛先アドレスに関連付ける際に、ネットワークレベルで発生します（セクション5.6）。イーサネット上のIPv4およびIPv6では、この関連は通常直接マッピングであり、これはULE [RFC4326]とMPE [ETSI-DAT]の両方で指定されているデフォルトの方法です。
Address resolution must also occur at the MPEG-2 level (Section 4). The goal of this multicast address resolution is to allow a Receiver to associate an IPv4 or IPv6 multicast address with a specific TS Logical Channel and the corresponding TS Multiplex [RFC4259]. This association needs to permit a large number of active multicast groups, and should minimize the processing load at the Receiver when filtering and forwarding IP multicast packets (e.g., by distributing the multicast traffic over a number of TS Logical Channels). Schemes that allow hardware filtering can be beneficial, since these may relieve the drivers and operating systems from discarding unwanted multicast traffic.
アドレス解像度は、MPEG-2レベル（セクション4）でも発生する必要があります。このマルチキャストアドレス解像度の目標は、受信者がIPv4またはIPv6マルチキャストアドレスを特定のTS論理チャネルと対応するTSマルチプレックス[RFC4259]に関連付けることを許可することです。この協会は、多数のアクティブなマルチキャストグループを許可する必要があり、IPマルチキャストパケットをフィルタリングおよび転送するときにレシーバーの処理負荷を最小限に抑える必要があります（たとえば、多数のTS論理チャネルにマルチキャストトラフィックを配布することにより）。ハードウェアフィルタリングを可能にするスキームは、ドライバーとオペレーティングシステムが不要なマルチキャストトラフィックを破棄することを緩和する可能性があるため、有益です。
There are two specific functions required for address resolution in IP multicast over MPEG-2 Networks:
MPEG-2ネットワークを介したIPマルチキャストのアドレス解像度に必要な2つの特定の関数があります。
(i) Mapping IP multicast groups to the underlying MPEG-2 TS Logical Channel (PID) and the MPEG-2 TS Multiplex at the Encapsulator.
(i) IPマルチキャストグループを基礎となるMPEG-2 TS論理チャネル（PID）およびMPEG-2 TSマルチプレックスにマッピングします。
(ii) Provide signalling information to allow a Receiver to locate an IP multicast flow within an MPEG-2 TS Multiplex.
（ii）受信者がMPEG-2 TSマルチプレックス内でIPマルチキャストフローを見つけることができるシグナリング情報を提供します。
Methods are required to identify the scope of an address when an MPEG-2 Network supports several logical IP networks and carries groups within different multicast scopes [RFC4259].
MPEG-2ネットワークがいくつかの論理IPネットワークをサポートし、異なるマルチキャストスコープ内のグループを運ぶ場合、アドレスの範囲を識別するには方法が必要です[RFC4259]。
Appropriate procedures need to specify the correct action when the same multicast group is available on separate TS Logical Channels. This could arise when different Encapsulators contribute IP packets with the same IP Group Destination Address in the ASM (Any-Source Multicast) address range. Another case arises when a Receiver could receive more than one copy of the same packet (e.g., when packets are replicated across different TS Logical Channels or even different TS Multiplexes, a method known as Simulcasting [ETSI-DAT]). At the IP level, the host/router may be unaware of this duplication and this needs to be detected by other means.
適切な手順は、同じマルチキャストグループが別々のTS論理チャネルで利用可能である場合、正しいアクションを指定する必要があります。これは、異なるカプセルがASM（Any-Source Multicast）アドレス範囲で同じIPグループ宛先アドレスを持つIPパケットを寄付すると発生する可能性があります。別のケースは、レシーバーが同じパケットの複数のコピーを受け取ることができる場合に発生します（たとえば、パケットが異なるTS論理チャネルまたは異なるTSマルチプレックスで複製された場合、Simulcasting [ETSI-DAT]と呼ばれる方法）。IPレベルでは、ホスト/ルーターがこの複製に気付いていない可能性があり、これは他の手段で検出する必要があります。
When the MPEG-2 Network is peered to the multicast-enabled Internet, an arbitrarily large number of IP multicast group destination addresses may be in use, and the set forwarded on the transmission network may be expected to vary significantly with time. Some uses of IP multicast employ a range of addresses to support a single application (e.g., ND [RFC2461], Layered Coding Transport (LCT) [RFC3451], and Wave and Equation Based Rate Control (WEBRC) [RFC3738]). The current set of active addresses may be determined dynamically via a multicast group membership protocol (e.g., Internet Group Management Protocol (IGMP) [RFC3376] and Multicast Listener Discovery (MLD) [RFC3810]), via multicast routing (e.g., Protocol Independent Multicast (PIM) [RFC4601]) and/or other means (e.g., [RFC3819] and [RFC4605]), however each active address requires a binding by the AR method. Therefore, there are advantages in using a method that does not need to explicitly advertise an AR binding for each IP traffic flow, but is able to distribute traffic across a number of L2 TS Logical Channels (e.g., using a hash/mapping that resembles the mapping from IP addresses to MAC addresses [RFC1112, RFC2464]). Such methods can reduce the volume of AR information that needs to be distributed, and reduce the AR processing.
MPEG-2ネットワークがマルチキャスト対応インターネットにピアリングされると、任意に多数のIPマルチキャストグループの宛先アドレスが使用されている可能性があり、送信ネットワーク上の設定が時間とともに大きく異なると予想される場合があります。IPマルチキャストのいくつかの用途は、単一のアプリケーション（ND [RFC2461]、レイヤードコーディングトランスポート（LCT）[RFC3451]、および波と方程式のレート制御（WEBRC）[RFC3738]）をサポートするためにさまざまなアドレスを採用しています。現在のアクティブアドレスのセットは、マルチキャストグループメンバーシッププロトコル（インターネットグループ管理プロトコル（IGMP）[RFC3376]およびマルチキャストリスナーディスカバリー（MLD）[RFC3810]）を介して、マルチキャストルーティング（例えば、プロトコル独立マルチキャスターズを介して動的に決定できます。（PIM）[RFC4601]）および/またはその他の手段（例：[RFC3819]および[RFC4605]）。ただし、各アクティブアドレスにはARメソッドによる結合が必要です。したがって、各IPトラフィックフローのARバインディングを明示的に宣伝する必要のない方法を使用することには利点がありますが、多くのL2 TS論理チャネルにトラフィックを配布することができます（たとえば、ハッシュ/マッピングを使用して、IPアドレスからMACアドレスへのマッピング[RFC1112、RFC2464]）。このような方法は、分散する必要があるAR情報の量を減らし、AR処理を減らすことができます。
Section 5.6 describes the binding of IP multicast addresses to MAC/NPA addresses.
セクション5.6では、MAC/NPAアドレスへのIPマルチキャストアドレスのバインディングについて説明します。
The first part of this section describes the role of MPEG-2 signalling to identify streams (TS Logical Channels [RFC4259]) within the L2 infrastructure.
このセクションの最初の部分では、L2インフラストラクチャ内のストリーム（TS論理チャネル[RFC4259]）を識別するMPEG-2シグナル伝達の役割について説明します。
At L2, the MPEG-2 Transport Stream [ISO-MPEG2] identifies the existence and format of a Stream, using a combination of two PSI tables: the Program Association Table (PAT) and entries in the program element loop of a Program Map Table (PMT). PMT Tables are sent infrequently and are typically small in size. The PAT is sent using the well-known PID value of 0X000. This table provides the correspondence between a program_number and a PID value. (The program_number is the numeric label associated with a program). Each program in the Table is associated with a specific PID value, used to identify a TS Logical Channel (i.e., a TS). The identified TS is used to send the PMT, which associates a set of PID values with the individual components of the program. This approach de-references the PID values when the MPEG-2 Network includes multiplexors or re-multiplexors that renumber the PID values of the TS Logical Channels that they process.
L2では、MPEG-2トランスポートストリーム[ISO-MPEG2]は、2つのPSIテーブルの組み合わせを使用して、ストリームの存在と形式を識別します。（PMT）。PMTテーブルはまれに送信され、通常はサイズが小さくなります。PATは、0x000のよく知られているPID値を使用して送信されます。このテーブルは、Program_NumberとPID値の間の対応を提供します。（Program_Numberは、プログラムに関連付けられた数値ラベルです）。テーブル内の各プログラムは、TS論理チャネル（つまり、TS）を識別するために使用される特定のPID値に関連付けられています。識別されたTSは、PMTを送信するために使用されます。PMTは、PID値のセットをプログラムの個々のコンポーネントと関連付けます。このアプローチは、MPEG-2ネットワークにマルチプレクサまたは再マルチプレクサーが含まれている場合にPID値を参照し、それらが処理するTS論理チャネルのPID値を変更します。
In addition to signalling the Receiver with the PID value assigned to a Stream, PMT entries indicate the presence of Streams using ULE and MPE to the variety of devices that may operate in the MPEG-2 transmission network (multiplexors, remultiplexors, rate shapers, advertisement insertion equipment, etc.).
PMTエントリは、PID値を使用して受信機に信号を送信することに加えて、MPEG-2トランスミッションネットワーク（マルチプレクサ、remultiplexors、レートシェイパー、広告）で動作するさまざまなデバイスにULEとMPEを使用してストリームの存在を示しています。挿入装置など）。
A multiplexor or remultiplexor may change the PID values associated with a Stream during the multiplexing process, the new value being reflected in an updated PMT. TS Packets that carry a PID value that is not associated with a PMT entry (an orphan PID), may, and usually will be dropped by ISO 13818-1 compliant L2 equipment, resulting in the Stream not being forwarded across the transmission network. In networks that do not employ any intermediate devices (e.g., scenarios C,E,F of [RFC4259]), or where devices have other means to determine the set of PID values in use, the PMT table may still be sent (but is not required for this purpose).
マルチプレクサーまたは再退屈性は、多重化プロセス中にストリームに関連付けられたPID値を変更する可能性があり、新しい値は更新されたPMTに反映されます。PMTエントリ（孤児pID）に関連付けられていないPID値を運ぶTSパケット、および通常、ISO 13818-1準拠のL2機器によって削除されるため、ストリームはトランスミッションネットワーク全体に転送されません。中間デバイスを使用していないネットワーク（例：シナリオC、E、[RFC4259]のF）、またはデバイスが使用中のPID値のセットを決定する他の手段を持っている場合、PMTテーブルはまだ送信される場合があります（ただしこの目的には必要ありません）。
Although the basic PMT information may be used to identify the existence of IP traffic, it does not associate a Stream with an IP prefix/address. The remainder of the section describes IP addresses resolution mechanisms relating to MPEG-2.
基本的なPMT情報は、IPトラフィックの存在を識別するために使用できますが、ストリームをIPプレフィックス/アドレスに関連付けません。セクションの残りの部分では、MPEG-2に関連するIPアドレス解像度メカニズムについて説明します。
The static mapping option, where IP addresses or flows are statically mapped to specific PIDs is the equivalent to signalling "out-of-band". The application programmer, installing engineer, or user receives the mapping via some outside means, not in the MPEG-2 TS. This is useful for testing, experimental networks, small subnetworks and closed domains.
IPアドレスまたはフローが特定のPIDに静的にマッピングされる静的マッピングオプションは、「帯域外」を信号することに相当します。アプリケーションプログラマー、インストールエンジニア、またはユーザーは、MPEG-2 TSではなく、一部の外部平均を介してマッピングを受信します。これは、テスト、実験ネットワーク、小規模なサブネットワーク、閉じたドメインに役立ちます。
A pre-defined set of IP addresses may be used within an MPEG-2 transmission network. Prior knowledge of the active set of addresses allows appropriate AR records to be constructed for each address, and to pre-assign the corresponding PID value (e.g., selected to optimize Receiver processing; to group related addresses to the same PID value; and/or to reflect a policy for usage of specific ranges of PID values). This presumes that the PID mappings are not modified during transmission (Section 4).
MPEG-2トランスミッションネットワーク内で、事前に定義されたIPアドレスセットを使用できます。アドレスのアクティブな知識の事前知識により、各アドレスに対して適切なARレコードを作成し、対応するPID値を事前に割り当てることができます（たとえば、受信機処理を最適化するために選択され、関連するアドレスを同じPID値にグループ化します。PID値の特定の範囲の使用に関するポリシーを反映するため）。これは、PIDマッピングが送信中に変更されていないことを前提としています（セクション4）。
A single "well-known" PID is a specialization of this. This scheme is used by current DOCSIS cable modems [DOCSIS], where all IP traffic is placed into the specified TS stream. MAC filtering (and/or Section filtering in MPE) may be used to differentiate subnetworks.
単一の「よく知られている」PIDは、これを専門としています。このスキームは、すべてのIPトラフィックが指定されたTSストリームに配置される現在のDocSISケーブルモデム[DOCSIS]によって使用されます。MACフィルタリング（および/またはMPEでのセクションフィルタリング）を使用して、サブネットワークを区別できます。
Cable networks use a different transmission scheme for downstream (head-end to cable modem) and upstream (cable modem to head-end) transmissions.
ケーブルネットワークは、下流（ヘッドエンドからケーブルモデム）および上流（ケーブルモデムからヘッドエンド）の送信に異なる伝送スキームを使用します。
IP/Ethernet packets are sent (on the downstream) to the cable modem(s) encapsulated in MPEG-2 TS Packets sent on a single well-known TS Logical Channel (PID). There is no use of in-band signalling tables. On the upstream, the common approach is to use Ethernet framing, rather than IP/Ethernet over MPEG-2, although other proprietary schemes also continue to be used.
IP/イーサネットパケットは、（下流で）、単一のよく知られているTS論理チャネル（PID）で送信されたMPEG-2 TSパケットにカプセル化されたケーブルモデムに送信されます。帯域内のシグナリングテーブルには使用されていません。上流では、一般的なアプローチは、MPEG-2を介したIP/イーサネットではなく、イーサネットフレーミングを使用することですが、他の独自のスキームも使用され続けています。
Until the deployment of DOCSIS and EuroDOCSIS, most address resolution schemes for IP traffic in cable networks were proprietary, and did not usually employ a table-based address resolution method. Proprietary methods continue to be used in some cases where cable modems require interaction. In this case, equipment at the head-end may act as gateways between the cable modem and the Internet. These gateways receive L2 information and allocate an IP address.
DOCSISとEurodocsisの展開まで、ほとんどのケーブルネットワークのIPトラフィックの住所解決スキームは独自であり、通常はテーブルベースのアドレス解決方法を使用しませんでした。ケーブルモデムに相互作用が必要な場合には、独自の方法が引き続き使用されます。この場合、ヘッドエンドの機器は、ケーブルモデムとインターネットの間のゲートウェイとして機能する場合があります。これらのゲートウェイは、L2情報を受信し、IPアドレスを割り当てます。
DOCSIS uses DHCP for IP client configuration. The Cable Modem Terminal System (CMTS) provides a DHCP Server that allocates IP addresses to DOCSIS cable modems. The MPEG-2 transmission network provides a L2 bridged network to the cable modem (Section 1). This usually acts as a DHCP Relay for IP devices [RFC2131], [RFC3046], and [RFC3256]. Issues in deployment of IPv6 are described in [RFC4779].
Docsisは、IPクライアント構成にDHCPを使用します。ケーブルモデム端子システム（CMTS）は、IPアドレスをDocSISケーブルモデムに割り当てるDHCPサーバーを提供します。MPEG-2トランスミッションネットワークは、ケーブルモデム（セクション1）にL2ブリッジネットワークを提供します。これは通常、IPデバイス[RFC2131]、[RFC3046]、および[RFC3256]のDHCPリレーとして機能します。IPv6の展開における問題は、[RFC4779]で説明されています。
The information about the set of MPEG-2 Transport Streams carried over a TS Multiplex can be distributed via SI/PSI Tables. These tables are usually sent periodically (Section 4). This design requires access to and processing of the SI Table information by each Receiver [ETSI-SI], [ETSI-SI1]. This scheme reflects the complexity of delivering and coordinating the various Transport Streams associated with multimedia TV. A TS Multiplex may provide AR information for IP services by integrating additional information into the existing control tables or by transmitting additional SI Tables that are specific to the IP service.
TSマルチプレックスに搭載されているMPEG-2トランスポートストリームのセットに関する情報は、Si/PSIテーブルを介して分散できます。これらの表は通常、定期的に送信されます（セクション4）。この設計では、各受信機[ETSI-SI]、[ETSI-SI1]によるSIテーブル情報へのアクセスと処理が必要です。このスキームは、マルチメディアテレビに関連するさまざまな輸送ストリームを提供および調整する複雑さを反映しています。TS Multiplexは、追加情報を既存のコントロールテーブルに統合するか、IPサービスに固有の追加のSIテーブルを送信することにより、IPサービスにAR情報を提供する場合があります。
Examples of MPEG-2 Table usage that allows an MPEG-2 Receiver to identify the appropriate PID and the multiplex associated with a specific IP address include:
MPEG-2レシーバーが適切なPIDと特定のIPアドレスに関連付けられた多重を識別できるようにするMPEG-2テーブルの使用の例は次のとおりです。
(i) IP/MAC Notification Table (INT) in the DVB Data standard [ETSI-DAT]. This provides unidirectional address resolution of IPv4/IPv6 multicast addresses to an MPEG-2 TS.
(i) DVBデータ標準[ETSI-DAT]のIP/MAC通知テーブル（INT）。これにより、MPEG-2 TSに対するIPv4/IPv6マルチキャストアドレスの単方向アドレス解像度が提供されます。
(ii) Application Information Table (AIT) in the Multimedia Home Platform (MHP) specifications [ETSI-MHP].
（ii）マルチメディアホームプラットフォーム（MHP）仕様[ETSI-MHP]のアプリケーション情報表（AIT）。
(iii) Multicast Mapping Table (MMT) is an MPEG-2 Table employed by some DVB-RCS systems to provide unidirectional address resolution of IPv4 multicast addresses to an MPEG-2 TS.
（iii）マルチキャストマッピングテーブル（MMT）は、いくつかのDVB-RCSシステムで採用されているMPEG-2テーブルで、MPEG-2 TSへのIPv4マルチキャストアドレスの単方向アドレス解像度を提供します。
The MMT and AIT are used for specific applications, whereas the INT [ETSI-DAT] is a more general DVB method that supports MAC, IPv4, and IPv6 AR when used in combination with the other MPEG-2 tables (Section 4).
MMTとAITは特定のアプリケーションに使用されますが、Int [ETSI-DAT]は、他のMPEG-2テーブルと組み合わせて使用する場合、MAC、IPv4、およびIPv6 ARをサポートするより一般的なDVBメソッドです（セクション4）。
The INT provides a set of descriptors to specify addressing in a DVB network. The use of this method is specified for Multiprotocol Encapsulation (MPE) [ETSI-DAT]. It provides a method for carrying information about the location of IP/L2 flows within a DVB network. A Platform_ID identifies the addressing scope for a set of IP/L2 streams and/or Receivers. A Platform may span several Transport Streams carried by one or multiple TS Multiplexes and represents a single IP network with a harmonized address space (scope). This allows for the coexistence of several independent IP/MAC address scopes within an MPEG-2 Network.
INTは、DVBネットワークでアドレス指定を指定するための記述子のセットを提供します。この方法の使用は、マルチプロトコルカプセル化（MPE）[ETSI-DAT]に指定されています。DVBネットワーク内のIP/L2フローの位置に関する情報を伝える方法を提供します。Platform_IDは、一連のIP/L2ストリームおよび/または受信機のアドレス指定範囲を識別します。プラットフォームは、1つまたは複数のTSマルチプレックスによって運ばれるいくつかの輸送ストリームにまたがり、調和したアドレス空間（スコープ）を備えた単一のIPネットワークを表します。これにより、MPEG-2ネットワーク内のいくつかの独立したIP/MACアドレススコープの共存が可能になります。
The INT allows both fully-specified IP addresses and prefix matching to reduce the size of the table (and hence enhance signalling efficiency). An IPv4/IPv6 "subnet mask" may be specified in full form or by using a slash notation (e.g., /127). IP multicast addresses can be specified with or without a source (address or range), although if a source address is specified, then only the slash notation may be used for prefixes.
INTにより、完全に指定されたIPアドレスとプレフィックスマッチングの両方がテーブルのサイズを縮小します（したがってシグナリング効率が向上します）。IPv4 /IPv6 "Subnet Mask"は、完全な形で、またはスラッシュ表記（ /127など）を使用して指定できます。IPマルチキャストアドレスは、ソース（アドレスまたは範囲）の有無にかかわらず指定できますが、ソースアドレスが指定されている場合、プレフィックスにはスラッシュ表記のみを使用できます。
In addition, for identification and security descriptors, the following descriptors are defined for address binding in INT tables:
さらに、識別記述子およびセキュリティ記述子の場合、INTテーブルのアドレスバインディング用に次の記述子が定義されています。
(i) target_MAC_address_descriptor: A descriptor to describe a single or set of MAC addresses (and their mask).
(i) Target_mac_address_descriptor：Macアドレス（およびそのマスク）の単一またはセットを記述する記述子。
(ii) target_MAC_address_range_descriptor: A descriptor that may be used to set filters.
（ii）Target_mac_address_range_descriptor：フィルターの設定に使用できる記述子。
(iii) target_IP_address_descriptor: A descriptor describing a single or set of IPv4 unicast or multicast addresses (and their mask).
（iii）Target_ip_address_descriptor：IPv4ユニキャストまたはマルチキャストアドレス（およびそのマスク）の単一またはセットを記述する記述子。
(iv) target_IP_slash_descriptor: Allows definition and announcement of an IPv4 prefix.
（iv）Target_ip_slash_descriptor：IPv4プレフィックスの定義と発表を許可します。
(v) target_IP_source_slash_descriptor: Uses source and destination addresses to target a single or set of systems.
(v) Target_ip_source_slash_descriptor：ソースアドレスと宛先アドレスを使用して、単一またはセットのシステムをターゲットにします。
(vi) IP/MAC stream_location_descriptor: A descriptor that locates an IP/MAC stream in a DVB network.
（vi）IP/Mac Stream_Location_Descriptor：DVBネットワークにIP/MACストリームを見つける記述子。
The following descriptors provide corresponding functions for IPv6 addresses:
次の記述子は、IPv6アドレスの対応する関数を提供します。
target_IPv6_address_descriptor target_IPv6_slash_descriptor and target_IPv6_source_slash_descriptor
Target_ipv6_address_descriptor target_ipv6_slash_descriptorおよびtarget_ipv6_source_slash_descriptor
The ISP_access_mode_descriptor allows specification of a second address descriptor to access an ISP via an alternative non-DVB (possibly non-IP) network.
ISP_ACCESS_MODE_DESCRIPTORを使用すると、2番目のアドレス記述子の仕様を使用して、代替の非DVB（おそらく非IP）ネットワークを介してISPにアクセスできます。
One key benefit is that the approach employs MPEG-2 signalling (Section 4) and is integrated with other signalling information. This allows the INT to operate in the presence of (re)multiplexors [RFC4259] and to refer to PID values that are carried in different TS Multiplexes. This makes it well-suited to a Broadcast TV Scenario [RFC4259].
重要な利点の1つは、このアプローチがMPEG-2シグナル伝達を採用しており（セクション4）、他のシグナリング情報と統合されていることです。これにより、INTは（RE）マルチプレクサ[RFC4259]の存在下で動作し、異なるTSマルチプレックスで運ばれるPID値を参照できます。これにより、放送テレビシナリオ[RFC4259]に適しています。
The principal drawback is a need for an Encapsulator to introduce associated PSI/SI MPEG-2 control information. This control information needs to be processed at a Receiver. This requires access to information below the IP layer. The position of this processing within the protocol stack makes it hard to associate the results with IP Policy, management, and security functions. The use of centralized management prevents the implementation of a more dynamic scheme.
主な欠点は、関連するPSI/SI MPEG-2制御情報を導入するためのカプセレータが必要です。この制御情報は、受信機で処理する必要があります。これには、IPレイヤー以下の情報へのアクセスが必要です。プロトコルスタック内でのこの処理の位置により、結果をIPポリシー、管理、およびセキュリティ機能に関連付けることが困難です。集中管理を使用すると、より動的なスキームの実装が妨げられます。
In DVB-RCS, unicast AR is seen as a part of a wider configuration and control function and does not employ a specific protocol.
DVB-RCSでは、ユニキャストARはより広い構成および制御機能の一部と見なされており、特定のプロトコルを使用していません。
A Multicast Mapping Table (MMT) may be carried in an MPEG-2 control table that associates a set of multicast addresses with the corresponding PID values [MMT]. This table allows a DVB-RCS Forward Link Subsystem (FLSS) to specify the mapping of IPv4 and IPv6 multicast addresses to PID values within a specific TS Multiplex. Receivers (DVB-RCS Return Channel Satellite Terminals (RCSTs)) may use this table to determine the PID values associated with an IP multicast flow that it requires to receive. The MMT is specified by the SatLabs Forum [MMT] and is not currently a part of the DVB-RCS specification.
マルチキャストマッピングテーブル（MMT）は、一連のマルチキャストアドレスを対応するPID値[MMT]に関連付けるMPEG-2コントロールテーブルに携帯できます。このテーブルを使用すると、DVB-RCSフォワードリンクサブシステム（FLSS）を使用して、特定のTSマルチプレックス内のPID値へのIPv4およびIPv6マルチキャストアドレスのマッピングを指定できます。受信機（DVB-RCSリターンチャネル衛星端子（RCSTS））は、このテーブルを使用して、受信する必要があるIPマルチキャストフローに関連付けられたPID値を決定できます。MMTはSatlabsフォーラム[MMT]によって指定されており、現在DVB-RCS仕様の一部ではありません。
The DVB Multimedia Home Platform (MHP) specification [ETSI-MHP] does not define a specific AR function. However, an Application Information Table (AIT) is defined that allows MHP Receivers to receive a variety of control information. The AIT uses an MPEG-2 signalling table, providing information about data broadcasts, the required activation state of applications carried by a broadcast stream, etc. This information allows a broadcaster to request that a Receiver change the activation state of an application, and to direct applications to receive specific multicast packet flows (using IPv4 or IPv6 descriptors). In MHP, AR is not seen as a specific function, but as a part of a wider configuration and control function.
DVBマルチメディアホームプラットフォーム（MHP）仕様[ETSI-MHP]は、特定のAR機能を定義しません。ただし、MHP受信機がさまざまな制御情報を受信できるようにするアプリケーション情報表（AIT）が定義されています。AITはMPEG-2シグナリングテーブルを使用して、データブロードキャスト、ブロードキャストストリームによって運ばれるアプリケーションの必要なアクティベーション状態に関する情報を提供します。この情報により、放送局は受信者がアプリケーションのアクティブ化状態を変更するように要求できます。特定のマルチキャストパケットフローを受信するための直接アプリケーション（IPv4またはIPv6記述子を使用）。MHPでは、ARは特定の関数ではなく、より広い構成および制御機能の一部として見られます。
ATSC [ATSC-A54A] defines a system that allows transmission of IP packets within an MPEG-2 Network. An MPEG-2 Program (defined by the PMT) may contain one or more applications [ATSC-A90] that include IP multicast streams [ATSC-A92]. IP multicast data are signalled in the PMT using a stream_type indicator of value 0x0D. A MAC address list descriptor [SCTE-1] may also be included in the PMT.
ATSC [ATSC-A54A]は、MPEG-2ネットワーク内のIPパケットの送信を可能にするシステムを定義します。MPEG-2プログラム（PMTで定義）には、IPマルチキャストストリーム[ATSC-A92]を含む1つ以上のアプリケーション[ATSC-A90]が含まれる場合があります。IPマルチキャストデータは、値0x0DのStream_Typeインジケーターを使用してPMTでシグナルになります。MACアドレスリスト記述子[SCTE-1]もPMTに含まれる場合があります。
The approach focuses on applications that serve the transmission network. A method is defined that uses MPEG-2 SI Tables to bind the IP multicast media streams and the corresponding Session Description Protocol (SDP) announcement streams to particular MPEG-2 Program Elements. Each application constitutes an independent network. The MPEG-2 Network boundaries establish the IP addressing scope.
このアプローチは、トランスミッションネットワークにサービスを提供するアプリケーションに焦点を当てています。MPEG-2 SIテーブルを使用してIPマルチキャストメディアストリームと、対応するセッション説明プロトコル（SDP）アナウンスストリームを特定のMPEG-2プログラム要素に結合するメソッドが定義されています。各アプリケーションは、独立したネットワークを構成します。MPEG-2ネットワークの境界は、IPアドレス指定範囲を確立します。
The MPEG-2 methods based on SI/PSI meet the specified requirements of the groups that created them and each has their strength: the INT in terms of flexibility and extensibility, the MMT in its simplicity, and the AIT in its extensibility. However, they exhibit scalability constraints, represent technology specific solutions, and do not fully adopt IP-centric approaches that would enable easier use of the MPEG-2 bearer as a link technology within the wider Internet.
SI/PSIに基づくMPEG-2メソッドは、それらを作成したグループとそれぞれの強度を持っているグループの指定された要件を満たしています。柔軟性と拡張性、そのシンプルさのMMT、およびその拡張性のAITの観点からです。ただし、スケーラビリティの制約を示し、テクノロジー固有のソリューションを表し、より広いインターネット内のリンクテクノロジーとしてMPEG-2ベアラーを容易に使用できるIP中心のアプローチを完全には採用しません。
As MPEG-2 Networks evolve to become multi-service networks, the use of IP protocols is becoming more prevalent. Most MPEG-2 Networks now use some IP protocols for operations and control and data delivery. Address resolution information could also be sent using IP transport. At the time of writing there is no standards-based IP-level AR protocol that supports the MPEG-2 TS.
MPEG-2ネットワークが進化してマルチサービスネットワークになるにつれて、IPプロトコルの使用がより一般的になりつつあります。ほとんどのMPEG-2ネットワークは、操作と制御およびデータ配信にいくつかのIPプロトコルを使用しています。アドレス解決情報は、IPトランスポートを使用して送信することもできます。執筆時点では、MPEG-2 TSをサポートする標準ベースのIPレベルARプロトコルはありません。
There is an opportunity to define an IP-level method that could use an IP multicast protocol over a well-known IP multicast address to resolve an IP address to a TS Logical Channel (i.e., a Transport Stream). The advantages of using an IP-based address resolution include: (i) Simplicity: The AR mechanism does not require interpretation of L2 tables; this is an advantage especially in the growing market share for home network and audio/video networked entities.
有名なIPマルチキャストアドレスを介してIPマルチキャストプロトコルを使用して、IPアドレスをTS論理チャネル（つまり、トランスポートストリーム）に解決できるIPレベルのメソッドを定義する機会があります。IPベースのアドレス解像度を使用することの利点は次のとおりです。（i）単純さ：ARメカニズムはL2テーブルの解釈を必要としません。これは、特にホームネットワークおよびオーディオ/ビデオネットワークエンティティの市場シェアの拡大における利点です。
(ii) Uniformity: An IP-based protocol can provide a common method across different network scenarios for both IP to MAC address mappings and mapping to TS Logical Channels (PID value associated with a Stream).
（ii）均一性：IPベースのプロトコルは、IPからMACアドレスマッピングとTSロジカルチャネルへのマッピング（ストリームに関連付けられたPID値）の両方の異なるネットワークシナリオで共通のメソッドを提供できます。
(iii) Extensibility: IP-based AR mechanisms allow an independent evolution of the AR protocol. This includes dynamic methods to request address resolution and the ability to include other L2 information (e.g., encryption keys).
（iii）拡張性：IPベースのARメカニズムにより、ARプロトコルの独立した進化が可能になります。これには、アドレス解像度と他のL2情報（暗号化キーなど）を含める機能を要求する動的な方法が含まれます。
(iv) Integration: The information exchanged by IP-based AR protocols can easily be integrated as a part of the IP network layer, simplifying support for AAA, policy, Operations and Management (OAM), mobility, configuration control, etc., that combine AR with security.
（iv）統合：IPベースのARプロトコルによって交換される情報は、IPネットワークレイヤーの一部として簡単に統合でき、AAA、ポリシー、運用、管理（OAM）、モビリティ、構成制御などのサポートを簡素化できます。ARとセキュリティを組み合わせます。
The drawbacks of an IP-based method include:
IPベースの方法の欠点には次のものがあります。
(i) It can not operate over an MPEG-2 Network that uses MPEG-2 remultiplexors [RFC4259] that modify the PID values associated with the TS Logical Channels during the multiplexing operation (Section 4). This makes the method unsuitable for use in deployed broadcast TV networks [RFC4259].
(i) MPEG-2 Remultiplexors [RFC4259]を使用するMPEG-2ネットワークを介して動作することはできません。これにより、多重化動作中にTS論理チャネルに関連付けられたPID値が変更されます（セクション4）。これにより、この方法は、展開されたブロードキャストTVネットワーク[RFC4259]で使用するのに適していません。
(ii) IP-based methods can introduce concerns about the integrity of the information and authentication of the sender [RFC4259]. (These concerns are also applicable to MPEG-2 Table methods, but in this case the information is confined to the L2 network, or parts of the network where gateway devices isolate the MPEG-2 devices from the larger Internet creating virtual MPEG-2 private networks.) IP-based solutions should therefore implement security mechanisms that may be used to authenticate the sender and verify the integrity of the AR information as a part of a larger security framework.
（ii）IPベースの方法では、送信者の情報と認証の完全性に関する懸念を導入できます[RFC4259]。（これらの懸念はMPEG-2テーブルメソッドにも適用されますが、この場合、情報はL2ネットワーク、またはゲートウェイデバイスがVirtual MPEG-2プライベートを作成する大きなインターネットからMPEG-2デバイスを隔離するネットワークの一部に限定されています。したがって、IPベースのソリューションは、送信者を認証し、より大きなセキュリティフレームワークの一部としてAR情報の整合性を検証するために使用できるセキュリティメカニズムを実装する必要があります。
An IP-level method could use an IP multicast protocol running an AR Server (see also Section 5.4) over a well-known (or discovered) IP multicast address. To satisfy the requirement for scalability to networks with a large number of systems (Section 1), a single packet needs to transport multiple AR records and define the intended scope for each address. Methods that employ prefix matching are desirable (e.g., where a range of source/destination addresses are matched to a single entry). It can also be beneficial to use methods that permit a range of IP addresses to be mapped to a set of TS Logical Channels (e.g., a hashing technique similar to the mapping of IP Group Destination Addresses to Ethernet MAC addresses [RFC1112] [RFC2464]).
IPレベルのメソッドは、よく知られている（または発見された）IPマルチキャストアドレスを介してARサーバーを実行しているIPマルチキャストプロトコル（セクション5.4も参照）を使用できます。多数のシステムを使用してネットワークのスケーラビリティの要件を満たすために（セクション1）、単一のパケットは複数のARレコードを輸送し、各アドレスの意図した範囲を定義する必要があります。プレフィックスマッチングを使用する方法が望ましい（たとえば、ソース/宛先アドレスの範囲が単一のエントリに一致する場合）。また、一連のTS論理チャネルにマッピングできるさまざまなIPアドレスを可能にする方法を使用することも有益です（たとえば、イーサネットMACアドレスへのIPグループ宛先アドレスのマッピングと同様のハッシュテクニック[RFC1112] [RFC2464]）。
This section reviews IETF protocols that may be used to assign and manage the mapping of IP addresses to/from MAC/NPA addresses over MPEG-2 Networks.
このセクションでは、MPEG-2ネットワークを介したMAC/NPAアドレスにIPアドレスのマッピングを割り当てて管理するために使用できるIETFプロトコルを確認します。
An IP Encapsulator requires AR information to select an appropriate MAC/NPA address in the SNDU header [RFC4259] (Section 6). The information to complete this header may be taken directly from a neighbor/ARP cache, or may require the Encapsulator to retrieve the information using an AR protocol. The way in which this information is collected will depend upon whether the Encapsulator functions as a Router (at L3) or a Bridge (at L2) (Section 1.1).
IPカプセレータは、SNDUヘッダー[RFC4259]（セクション6）で適切なMAC/NPAアドレスを選択するためにAR情報を必要とします。このヘッダーを完成させるための情報は、Neighbor/ARPキャッシュから直接取得される場合があります。または、ARプロトコルを使用して情報を取得するためにエンコープカプレータが必要になる場合があります。この情報が収集される方法は、カプセレータがルーター（L3）またはブリッジ（L2）として機能するかどうか（セクション1.1）に依存します。
Two IETF-defined protocols for mapping IP addresses to MAC/NPA addresses are the Address Resolution Protocol, ARP [RFC826], and the Neighbor Discovery protocol, ND [RFC2461], respectively for IPv4 and IPv6. Both protocols are normally used in a bidirectional mode, although both also permit unsolicited transmission of mappings. The IPv6 mapping defined in [RFC2464] can result in a large number of active MAC multicast addresses (e.g., one for each end host).
IPアドレスをMAC/NPAアドレスにマッピングするための2つのIETF定義プロトコルは、それぞれIPv4およびIPv6のアドレス解像度プロトコル[RFC826]とNeagerive Discovery Protocol、ND [RFC2461]です。両方のプロトコルは通常、双方向モードで使用されますが、どちらもマッピングの未承諾伝送も可能です。[RFC2464]で定義されているIPv6マッピングは、多数のアクティブなMACマルチキャストアドレス（たとえば、各エンドホストに1つ）をもたらす可能性があります。
ARP requires support for L2 broadcast packets. A large number of Receivers can lead to a proportional increase in ARP traffic, a concern for bandwidth-limited networks. Transmission delay can also impact protocol performance.
ARPには、L2ブロードキャストパケットのサポートが必要です。多数のレシーバーは、帯域幅が制限されたネットワークの懸念であるARPトラフィックの比例的な増加につながる可能性があります。伝送遅延は、プロトコルのパフォーマンスにも影響を与える可能性があります。
ARP also has a number of security vulnerabilities. ARP spoofing is where a system can be fooled by a rogue device that sends a fictitious ARP RESPONSE that includes the IP address of a legitimate network system and the MAC of a rogue system. This causes legitimate systems on the network to update their ARP tables with the false mapping and then send future packets to the rogue system instead of the legitimate system. Using this method, a rogue system can see (and modify) packets sent through the network.
ARPには、多くのセキュリティの脆弱性もあります。ARPスプーフィングは、正当なネットワークシステムのIPアドレスと不正システムのMACを含む架空のARP応答を送信するRogueデバイスによってシステムをだまされる可能性がある場合です。これにより、ネットワーク上の正当なシステムにより、誤ったマッピングでARPテーブルを更新し、正当なシステムではなくRogueシステムに将来のパケットを送信します。この方法を使用して、ローグシステムはネットワークを介して送信されたパケットを表示（および変更）できます。
Secure ARP (SARP) uses a secure tunnel (e.g., between each client and a server at a wireless access point or router) [RFC4346]. The router ignores any ARP RESPONSEs not associated with clients using the secure tunnels. Therefore, only legitimate ARP RESPONSEs are used for updating ARP tables. SARP requires the installation of software at each client. It suffers from the same scalability issues as the standard ARP.
Secure ARP（SARP）は、安全なトンネルを使用します（たとえば、ワイヤレスアクセスポイントまたはルーターで各クライアントとサーバーの間）[RFC4346]。ルーターは、安全なトンネルを使用してクライアントに関連付けられていないARP応答を無視します。したがって、ARPテーブルの更新には正当なARP応答のみが使用されます。SARPには、各クライアントにソフトウェアをインストールする必要があります。標準ARPと同じスケーラビリティの問題に苦しんでいます。
The ND protocol uses a set of IP multicast addresses. In large networks, many multicast addresses are used, but each client typically only listens to a restricted set of group destination addresses and little traffic is usually sent in each group. Therefore, Layer 2 AR for MPEG-2 Networks must support this in a scalable manner.
NDプロトコルは、一連のIPマルチキャストアドレスを使用します。大規模なネットワークでは、多くのマルチキャストアドレスが使用されますが、各クライアントは通常、グループ宛先アドレスの制限されたセットにのみ耳を傾け、通常は各グループでトラフィックが少なくなります。したがって、MPEG-2ネットワークのレイヤー2 ARは、これをスケーラブルな方法でサポートする必要があります。
A large number of ND messages may cause a large demand for performing asymmetric operations. The base ND protocol limits the rate at which multicast responses to solicitations can be sent. Configurations may need to be tuned when operating with large numbers of Receivers.
多数のNDメッセージは、非対称操作を実行するために大きな需要を引き起こす可能性があります。ベースNDプロトコルは、勧誘に対するマルチキャスト応答を送信できる速度を制限します。多数のレシーバーで操作するときは、構成を調整する必要がある場合があります。
The default parameters specified in the ND protocol [RFC2461] can introduce interoperability problems (e.g., a failure to resolve when the link RTT (round-trip time) exceed 3 seconds) and performance degradation (duplicate ND messages with a link RTT > 1 second) when used in networks where the link RTT is significantly larger than experienced by Ethernet LANs. Tuning of the protocol parameters (e.g., RTR_SOLICITATION_INTERVAL) is therefore recommended when using network links with appreciable delay (Section 6.3.2 of [RFC2461]).
NDプロトコル[RFC2461]で指定されているデフォルトのパラメーターは、相互運用性の問題（例えば、リンクRTT（ラウンドトリップ時間）が3秒を超えるときに解決できない場合）とパフォーマンスの劣化（リンクRTT> 1秒でNDメッセージを重複させることができます。）リンクRTTがイーサネットLANの経験よりも大幅に大きいネットワークで使用する場合。したがって、プロトコルパラメーターの調整（rtr_solicitation_intervalなど）は、かなりの遅延を持つネットワークリンクを使用する場合に推奨されます（[RFC2461]のセクション6.3.2）。
ND has similar security vulnerabilities to ARP. The Secure Neighbor Discovery (SEND) [RFC3971] was developed to address known security vulnerabilities in ND [RFC3756]. It can also reduce the AR traffic compared to ND. In addition, SEND does not require the configuration of per-host keys and can coexist with the use of both SEND and insecure ND on the same link.
NDは、ARPに対して同様のセキュリティの脆弱性を持っています。安全な近隣発見（SEND）[RFC3971]は、ND [RFC3756]の既知のセキュリティの脆弱性に対処するために開発されました。また、NDと比較してARトラフィックを減らすことができます。さらに、Sendはホストごとのキーの構成を必要とせず、同じリンクでSendと不安定なNDの両方を使用することと共存できます。
The ND Protocol is also used by IPv6 systems to perform other functions beyond address resolution, including Router Solicitation / Advertisement, Duplicate Address Detection (DAD), Neighbor Unreachability Detection (NUD), and Redirect. These functions are useful for hosts, even when address resolution is not required.
NDプロトコルは、IPv6システムでも使用され、ルーターの勧誘 /広告、複製アドレス検出（DAD）、近隣の到達不能検出（NUD）、リダイレクトなど、アドレス解決を超えた他の機能を実行します。これらの関数は、アドレス解決が不要な場合でも、ホストに役立ちます。
MPEG-2 Networks may provide a Unidirectional Broadcast Link (UDL), with no return path. Such links may be used for unicast applications that do not require a return path (e.g., based on UDP), but commonly are used for IP multicast content distribution.
MPEG-2ネットワークは、リターンパスなしで、単方向ブロードキャストリンク（UDL）を提供する場合があります。このようなリンクは、リターンパス（UDPに基づく）を必要としないユニキャストアプリケーションに使用できますが、一般にIPマルチキャストコンテンツの分布に使用されます。
/-----\
MPEG-2 Uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider + v MPEG-2 Downlink
+-----------+ |
+-----v------+
| MPEG-2 |
| Receiver |
+------------+
Figure 3: Unidirectional connectivity
図3：単方向接続
The ARP and ND protocols require bidirectional L2/L3 connectivity. They do not provide an appropriate method to resolve the remote (destination) address in a unidirectional environment.
ARPおよびNDプロトコルには、双方向L2/L3接続が必要です。それらは、一方向の環境でリモート（宛先）アドレスを解決する適切な方法を提供しません。
Unidirectional links therefore require a separate out-of-band configuration method to establish the appropriate AR information at the Encapsulator and Receivers. ULE [RFC4326] defines a mode in which the MAC/NPA address is omitted from the SNDU. In some scenarios, this may relieve an Encapsulator of the need for L2 AR.
したがって、単方向リンクには、エンコープカプレータおよびレシーバーで適切なAR情報を確立するために、個別の帯域外構成方法が必要です。ule [rfc4326]は、SNDUからMAC/NPAアドレスが省略されるモードを定義します。いくつかのシナリオでは、これはL2 ARの必要性のカプセレータを緩和する場合があります。
Bidirectional connectivity may be realized using a unidirectional link in combination with another network path. Common combinations are a Feed link using MPEG-2 satellite transmission and a return link using terrestrial network infrastructure. This topology is often known as a Hybrid network and has asymmetric network routing.
双方向の接続性は、別のネットワークパスと組み合わせて単方向リンクを使用して実現できます。一般的な組み合わせは、MPEG-2衛星伝送を使用したフィードリンクと、地上ネットワークインフラストラクチャを使用したリターンリンクです。このトポロジーはしばしばハイブリッドネットワークとして知られており、非対称ネットワークルーティングがあります。
/-----\
MPEG-2 uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider +-<-+ v MPEG-2 downlink
+-----------+ | |
| +-----v------+
+--<<--+ MPEG-2 |
Return | Receiver |
Path +------------+
Figure 4: Bidirectional connectivity
図4：双方向接続
The Unidirectional Link Routing (UDLR) [RFC3077] protocol may be used to overcome issues associated with asymmetric routing. The Dynamic Tunnel Configuration Protocol (DTCP) enables automatic configuration of the return path. UDLR hides the unidirectional routing from the IP and upper layer protocols by providing a L2 tunnelling mechanism that emulates a bidirectional broadcast link at L2. A network using UDLR has a topology where a Feed Router and all Receivers form a logical Local Area Network. Encapsulating L2 frames allows them to be sent through an Internet Path (i.e., bridging).
単方向リンクルーティング（UDLR）[RFC3077]プロトコルは、非対称ルーティングに関連する問題を克服するために使用できます。動的トンネル構成プロトコル（DTCP）は、リターンパスの自動構成を可能にします。UDLRは、L2で双方向ブロードキャストリンクをエミュレートするL2トンネルメカニズムを提供することにより、IPおよび上層プロトコルからの単方向ルーティングを隠します。UDLRを使用するネットワークには、フィードルーターとすべての受信機が論理的なローカルエリアネットワークを形成するトポロジがあります。L2フレームをカプセル化すると、インターネットパス（つまり、ブリッジング）を介して送信できます。
Since many unidirectional links employ wireless technology for the forward (Feed) link, there may be an appreciable cost associated with forwarding traffic on the Feed link. Therefore, it is often desirable to prevent forwarding unnecessary traffic (e.g., for multicast this implies control of which groups are forwarded). The implications of forwarding in the return direction must also be considered (e.g., asymmetric capacity and loss [RFC3449]). This suggests a need to minimize the volume and frequency of control messages.
多くの単方向リンクは、フォワード（フィード）リンクにワイヤレステクノロジーを採用しているため、フィードリンクのトラフィックの転送に関連するかなりのコストがある可能性があります。したがって、不要なトラフィックの転送を防ぐことが望ましいことがよくあります（たとえば、マルチキャストの場合、これはどのグループが転送されるかを制御することを意味します）。戻り方向への転送の意味も考慮する必要があります（例：非対称容量と損失[RFC3449]）。これは、コントロールメッセージの体積と頻度を最小限に抑える必要があることを示唆しています。
Three different AR cases may be identified (each considers sending an IP packet to a next-hop IP address that is not currently cached by the sender):
3つの異なるARケースが特定される場合があります（それぞれが、現在送信者によってキャッシュされていないネクストホップIPアドレスにIPパケットを送信することを検討します）：
(i) A Feed Router needs a Receiver MAC/NPA address.
(i) フィードルーターには、レシーバーMAC/NPAアドレスが必要です。
This occurs when a Feed Router sends an IP packet using the Feed UDL to a Receiver whose MAC/NPA address is unknown. In IPv4, the Feed Router sends an ARP REQUEST with the IP address of the Receiver. The Receiver that recognizes its IP address replies with an ARP RESPONSE to the MAC/NPA address of the Feed Router (e.g., using a UDLR tunnel). The Feed Router may then address IP packets to the unicast MAC/NPA address associated with the Receiver. The ULE encapsulation format also permits packets to be sent without specifying a MAC/NPA address, where this is desirable (Section 6.1 and 6.5).
これは、フィードルーターがフィードUDLを使用してMAC/NPAアドレスが不明であるレシーバーにIPパケットを送信するときに発生します。IPv4では、フィードルーターはレシーバーのIPアドレスでARPリクエストを送信します。IPアドレスを認識する受信機は、フィードルーターのMAC/NPAアドレス（UDLRトンネルを使用するなど）に対するARP応答で応答します。フィードルーターは、受信機に関連付けられているユニキャストMAC/NPAアドレスへのIPパケットをアドレス指定できます。ULEカプセル化形式では、MAC/NPAアドレスを指定せずにパケットを送信できます。
(ii) A Receiver needs the Feed Router MAC/NPA address.
（ii）受信機には、フィードルーターMAC/NPAアドレスが必要です。
This occurs when a Receiver sends an IP packet to a Feed Router whose MAC/NPA address is unknown. In IPv4, the Receiver sends an ARP REQUEST with the IP address of the Feed Router (e.g., using a UDLR tunnel). The Feed Router replies with an ARP RESPONSE using the Feed UDL. The Receiver may then address IP packets to the MAC/NPA address of the recipient.
これは、レシーバーがMAC/NPAアドレスが不明なフィードルーターにIPパケットを送信するときに発生します。IPv4では、受信機はフィードルーターのIPアドレスを使用してARP要求を送信します（例：UDLRトンネルを使用）。フィードルーターは、フィードUDLを使用してARP応答で応答します。レシーバーは、受信者のMAC/NPAアドレスへのIPパケットを扱うことができます。
(iii) A Receiver needs another Receiver MAC/NPA address.
（iii）レシーバーには別のレシーバーMAC/NPAアドレスが必要です。
This occurs when a Receiver sends an IP packet to another Receiver whose MAC/NPA address is unknown. In IPv4, the Receiver sends an ARP REQUEST with the IP address of the remote Receiver (e.g., using a UDLR tunnel to the Feed Router). The request is forwarded over the Feed UDL. The target Receiver replies with an ARP RESPONSE (e.g., using a UDLR tunnel). The Feed Router forwards the response on the UDL. The Receiver may then address IP packets to the MAC/NPA address of the recipient.
これは、受信者がMAC/NPAアドレスが不明な別のレシーバーにIPパケットを送信するときに発生します。IPv4では、レシーバーはリモートレシーバーのIPアドレスを使用してARPリクエストを送信します（たとえば、UDLRトンネルをフィードルーターに使用します）。リクエストは、フィードUDLに転送されます。ターゲットレシーバーは、ARP応答（UDLRトンネルを使用するなど）で応答します。フィードルーターは、UDL上の応答を転送します。レシーバーは、受信者のMAC/NPAアドレスへのIPパケットを扱うことができます。
These 3 cases allow any system connected to the UDL to obtain the MAC/NPA address of any other system. Similar exchanges may be performed using the ND protocol for IPv6.
これらの3つのケースにより、UDLに接続されたシステムが他のシステムのMAC/NPAアドレスを取得します。IPv6のNDプロトコルを使用して、同様の交換を実行できます。
A long round trip delay (via the UDL and UDLR tunnel) impacts the performance of the reactive address resolution procedures provided by ARP, ND, and SEND. In contrast to Ethernet, during the interval when resolution is taking place, many IP packets may be received that are addressed to the AR Target address. The ARP specification allows an interface to discard these packets while awaiting the response to the resolution request. An appropriately sized buffer would however prevent this loss.
（UDLおよびUDLRトンネルを介した）長い往復遅延は、ARP、ND、および送信によって提供されるリアクティブアドレス解決手順のパフォーマンスに影響を与えます。イーサネットとは対照的に、解像度が行われている間隔中に、ARターゲットアドレスにアドレス指定された多くのIPパケットが受信される場合があります。ARP仕様により、解像度リクエストへの応答を待っている間、インターフェイスがこれらのパケットを破棄することができます。ただし、適切にサイズのバッファーはこの損失を防ぎます。
In case (iii), the time to complete address resolution may be reduced by the use of an AR Server at the Feed (Section 5.4).
場合（iii）、アドレス解像度を完了するまでの時間は、フィードでARサーバーを使用することで短縮される場合があります（セクション5.4）。
Using DHCP requires prior establishment of the L2 connectivity to a DHCP Server. The delay in establishing return connectivity in UDLR networks that use DHCP, may make it beneficial to increase the frequency of the DTCP HELLO message. Further information about tuning DHCP is provided in Section 5.5.
DHCPを使用するには、DHCPサーバーへのL2接続を事前に確立する必要があります。DHCPを使用するUDLRネットワークでのリターン接続の確立の遅延により、DTCP Helloメッセージの頻度を増やすことが有益になる場合があります。チューニングDHCPの詳細については、セクション5.5に記載されています。
Bidirectional IP networks can be and are constructed by a combination of two MPEG-2 transmission links. One link is usually a broadcast link that feeds a set of remote Receivers. Links are also provided from Receivers so that the combined link functions as a full duplex interface. Examples of this use include two-way DVB-S satellite links and the DVB-RCS system.
双方向IPネットワークは、2つのMPEG-2伝送リンクの組み合わせによって構築できます。通常、1つのリンクは、リモートレシーバーのセットをフィードするブロードキャストリンクです。リンクはレシーバーからも提供されているため、複合リンクが完全なデュプレックスインターフェイスとして機能します。この使用の例には、双方向DVB-S衛星リンクとDVB-RCSシステムが含まれます。
An AR Server can be used to distribute AR information to Receivers in an MPEG-2 Network. In some topologies, this may significantly reduce the time taken for Receivers to discover AR information.
ARサーバーを使用して、AR情報をMPEG-2ネットワーク内の受信機に配布できます。一部のトポロジでは、これにより、受信機がAR情報を発見するのにかかる時間を大幅に短縮する可能性があります。
The AR Server can operate as a proxy responding on behalf of Receivers to received AR requests. When an IPv4 AR request is received (e.g., Receiver ARP REQUEST), an AR Server responds by (proxy) sending an AR response, providing the appropriate IP to MAC/NPA binding (mapping the IP address to the L2 address).
ARサーバーは、受信者に代わってARリクエストを受信するプロキシとして動作することができます。IPv4 ARリクエストが受信されると（例：受信者ARP要求）、ARサーバーはAR応答を送信し、MAC/NPAバインディングに適切なIPを提供することで応答します（L2アドレスにIPアドレスをマッピングします）。
Information may also be sent unsolicited by the AR Server using multicast/broadcast to update the ARP/neighbor cache at the Receivers without the need for explicit requests. The unsolicited method can improve scaling in large networks. Scaling could be further improved by distributing a single broadcast/multicast AR message that binds multiple IP and MAC/NPA addresses. This reduces the network capacity consumed and simplifies client/server processing in networks with large numbers of clients.
また、明示的なリクエストを必要とせずにレシーバーでARP/ネイバーキャッシュを更新するために、マルチキャスト/ブロードキャストを使用してARサーバーによって情報を未承諾を送信することもできます。未承諾の方法は、大規模なネットワークでのスケーリングを改善できます。複数のIPおよびMAC/NPAアドレスを結合する単一のブロードキャスト/マルチキャストARメッセージを配布することにより、スケーリングをさらに改善できます。これにより、消費されるネットワーク容量が削減され、多数のクライアントとのネットワークでのクライアント/サーバー処理が簡素化されます。
An AR Server can be implemented using IETF-defined Protocols by configuring the subnetwork so that AR Requests from Receivers are intercepted rather than forwarded to the Feed/broadcast link. The intercepted messages are sent to an AR Server. The AR Server maintains a set of MAC/NPA address bindings. These may be configured or may learned by monitoring ARP messages sent by Receivers. Currently defined IETF protocols only allow one binding per message (i.e., there is no optimization to conserve L2 bandwidth).
Subnetworkを構成することにより、IETF定義のプロトコルを使用してARサーバーを実装して、受信機からのAR要求がフィード/ブロードキャストリンクに転送されるのではなく傍受されるように実装できます。インターセプトされたメッセージはARサーバーに送信されます。ARサーバーは、MAC/NPAアドレスバインディングのセットを維持します。これらは、受信機によって送信されたARPメッセージを監視することにより、構成または学習することができます。現在定義されているIETFプロトコルは、メッセージごとに1つのバインディングのみを許可します（つまり、L2帯域幅を節約するための最適化はありません）。
Equivalent methods could provide IPv6 AR. Procedures for intercepting ND messages are defined in [RFC4389]. To perform an AR Server function, the AR information must also be cached. A caching AR proxy stores the system state within a middle-box device. This resembles a classic man-in-the-middle security attack; interactions with SEND are described in [SP-ND].
同等の方法では、IPv6 ARを提供できます。NDメッセージを傍受する手順は、[RFC4389]で定義されています。ARサーバー関数を実行するには、AR情報もキャッシュする必要があります。キャッシュARプロキシは、ミドルボックスデバイス内にシステム状態を保存します。これは、古典的な中間のセキュリティ攻撃に似ています。送信との相互作用は[SP-ND]で説明されています。
Methods are needed to purge stale AR data from the cache. The consistency of the cache must also be considered when the Receiver bindings can change (e.g., IP mobility, network topology changes, or intermittent Receiver connectivity). In these cases, the use of old (stale) information can result in IP packets being directed to an inappropriate L2 address, with consequent packet loss.
古いARデータをキャッシュからパージするには、方法が必要です。また、受信機のバインディングが変更される可能性がある場合（IPモビリティ、ネットワークトポロジの変更、または断続的な受信機の接続）が変更できる場合にも、キャッシュの一貫性を考慮する必要があります。これらの場合、古い（古い）情報を使用すると、IPパケットが不適切なL2アドレスに向けられ、結果としてパケット損失が発生する可能性があります。
Current IETF-defined methods provide bindings of IP addresses to MAC/NPA, but do not allow the bindings to other L2 information pertinent to MPEG-2 Networks, requiring the use of other methods for this function (Section 4). AR Servers can also be implemented using non-IETF AR protocols to provide the AR information required by Receivers.
現在のIETF定義のメソッドは、MAC/NPAへのIPアドレスのバインディングを提供しますが、MPEG-2ネットワークに関連する他のL2情報へのバインディングを許可しないため、この関数に他の方法を使用する必要があります（セクション4）。ARサーバーは、非ITF ARプロトコルを使用して実装して、受信機が必要とするAR情報を提供することもできます。
DHCP [RFC2131] and DHCPv6 [RFC3315] may be used over MPEG-2 Networks with bidirectional connectivity. DHCP consists of two components: a protocol for delivering system-specific configuration parameters from a DHCP Server to a DHCP Client (e.g., default router, DNS server) and a mechanism for the allocation of network addresses to systems.
DHCP [RFC2131]およびDHCPV6 [RFC3315]は、双方向接続を備えたMPEG-2ネットワークで使用できます。DHCPは、DHCPサーバーからDHCPクライアント（デフォルトルーター、DNSサーバーなど）にシステム固有の構成パラメーターを配信するためのプロトコルと、ネットワークアドレスをシステムに割り当てるメカニズムの2つのコンポーネントで構成されています。
The configuration of DHCP Servers and DHCP Clients should take into account the local link round trip delay (possibly including the additional delay from bridging, e.g., using UDLR). A large number of clients can make it desirable to tune the DHCP lease duration and the size of the address pool. Appropriate timer values should also be selected: the DHCP messages retransmission timeout, and the maximum delay that a DHCP Server waits before deciding that the absence of an ICMP echo response indicates that the relevant address is free.
DHCPサーバーとDHCPクライアントの構成では、ローカルリンクの往復遅延を考慮に入れる必要があります（たとえば、udlrの使用などのブリッジングによる追加の遅延を含む）。多数のクライアントは、DHCPリース期間とアドレスプールのサイズを調整することを望ましいものにすることができます。適切なタイマー値も選択する必要があります。DHCPメッセージの再送信タイムアウトとDHCPサーバーが待機する最大遅延は、ICMPエコー応答がないことが関連するアドレスが無料であることを示すことを決定する前に待機します。
DHCP Clients may retransmit DHCP messages if they do not receive a response. Some client implementations specify a timeout for the DHCPDISCOVER message that is small (e.g., suited to Ethernet delay, rather than appropriate to an MPEG-2 Network) providing insufficient time for a DHCP Server to respond to a DHCPDISCOVER retransmission before expiry of the check on the lease availability (by an ICMP Echo Request), resulting in potential address conflict. This value may need to be tuned for MPEG-2 Networks.
DHCPクライアントは、応答を受け取らない場合、DHCPメッセージを再送信する場合があります。一部のクライアントの実装では、DHCPDISCOVERメッセージのタイムアウトを指定します（たとえば、MPEG-2ネットワークに適したものではなく、イーサネットの遅延に適したもの）。DHCPサーバーがDHCPDiscoverの再送信に応答するのに不十分な時間を提供します。リースの可用性（ICMPエコーリクエストによる）により、潜在的な住所の競合が発生します。この値は、MPEG-2ネットワーク用に調整する必要がある場合があります。
Section 3.2 describes the multicast address resolution requirements. This section describes L3 address bindings when the destination network-layer address is an IP multicast Group Destination Address.
セクション3.2では、マルチキャストアドレス解決要件について説明します。このセクションでは、宛先ネットワーク層アドレスがIPマルチキャストグループの宛先アドレスである場合、L3アドレスバインディングについて説明します。
In MPE [ETSI-DAT], a mapping is specified for the MAC Address based on the IP multicast address for IPv4 [RFC1112] and IPv6 [RFC2464]. (A variant of DVB (DVB-H) uses a modified MAC header [ETSI-DAT]).
MPE [ETSI-DAT]では、IPv4 [RFC1112]およびIPv6 [RFC2464]のIPマルチキャストアドレスに基づいて、MACアドレスにマッピングが指定されています。（DVB（DVB-H）のバリアントは、変更されたMacヘッダー[ETSI-DAT]を使用します）。
In ULE [RFC4326], the L2 NPA address is optional, and is not necessarily required when the Receiver is able to perform efficient L3 multicast address filtering. When present, a mapping is defined based on the IP multicast address for IPv4 [RFC1112] and IPv6 [RFC2464].
ULE [RFC4326]では、L2 NPAアドレスはオプションであり、受信機が効率的なL3マルチキャストアドレスフィルタリングを実行できる場合は必ずしも必要ではありません。存在する場合、マッピングはIPv4 [RFC1112]およびIPv6 [RFC2464]のIPマルチキャストアドレスに基づいて定義されます。
The L2 group addressing method specified in [RFC1112] and [RFC2464] can result in more than one IP destination address being mapped to the same L2 address. In Source-Specific Multicast, SSM [RFC3569], multicast groups are identified by the combination of the IP source and IP destination addresses. Therefore, senders may independently select an IP group destination address that could map to the same L2 address if forwarded onto the same L2 link. The resulting addressing overlap at L2 can increase the volume of traffic forwarded to L3, where it then needs to be filtered.
[RFC1112]および[RFC2464]で指定されたL2グループアドレス指定方法により、同じL2アドレスに複数のIP宛先アドレスがマッピングされる可能性があります。ソース固有のマルチキャストであるSSM [RFC3569]では、マルチキャストグループがIPソースとIP宛先アドレスの組み合わせによって識別されます。したがって、送信者は、同じL2リンクに転送された場合、同じL2アドレスにマッピングできるIPグループの宛先アドレスを個別に選択できます。結果として生じるL2でのアドレス指定のオーバーラップは、L3に転送されるトラフィックの量を増加させる可能性があり、そこでフィルタリングする必要があります。
These considerations are the same as for Ethernet LANs, and may not be of concern to Receivers that can perform efficient L3 filtering. Section 3 noted that an MPEG-2 Network may need to support multiple addressing scopes at the network and link layers. Separation of the different groups into different Transport Streams is one remedy (with signalling of IP to PID value mappings). Another approach is to employ alternate MAC/NPA mappings to those defined in [RFC1112] and [RFC2464], but such mappings need to be consistently bound at the Encapsulator and Receiver, using AR procedures in a scalable manner.
これらの考慮事項は、イーサネットLANSと同じであり、効率的なL3フィルタリングを実行できるレシーバーにとっては懸念されない可能性があります。セクション3は、MPEG-2ネットワークは、ネットワークレイヤーとリンクレイヤーで複数のアドレス指定スコープをサポートする必要がある場合があることに注意しました。異なるグループを異なる輸送ストリームに分離することは、1つの治療法です（PID値マッピングへのIPのシグナリングを使用）。別のアプローチは、[RFC1112]および[RFC2464]で定義されているものに代替MAC/NPAマッピングを使用することですが、そのようなマッピングは、AR手順をスケーラブルな方法で使用して、エンカプセーターとレシーバーで一貫して結合する必要があります。
UDLR is a Layer 2 solution, in which a Receiver may send multicast/broadcast frames that are subsequently forwarded natively by a Feed Router (using the topology in Figure 2), and are finally received at the Feed interface of the originating Receiver. This multicast forwarding does not include the normal L3 Reverse Path Forwarding (RPF) check or L2 spanning tree checks, the processing of the IP Time To Live (TTL) field or the filtering of administratively scoped multicast addresses. This raises a need to carefully consider multicast support. To avoid forwarding loops, RFC 3077 notes that a Receiver needs to be configured with appropriate filter rules to ensure that it discards packets that originate from an attached network and are later received over the Feed link.
UDLRはレイヤー2ソリューションであり、受信機はその後、フィードルーターによってネイティブに転送されるマルチキャスト/ブロードキャストフレームを送信できます（図2のトポロジを使用）、最終的に発信元の受信機のフィードインターフェイスで受信されます。このマルチキャスト転送には、通常のL3逆パス転送（RPF）チェックまたはL2スパニングツリーチェック、Live（TTL）フィールドの処理、または管理上スコープされたマルチキャストアドレスのフィルタリングは含まれません。これにより、マルチキャストサポートを慎重に検討する必要があります。ループの転送を避けるために、RFC 3077は、添付のネットワークから発生し、後でフィードリンクを介して受信されるパケットを破棄するために、適切なフィルタールールで受信機を構成する必要があることに注意してください。
When the encapsulation includes an MAC/NPA source address, re-broadcast packets may be filtered at the link layer using a filter that discards L2 addresses that are local to the Receiver. In some circumstances, systems can send packets with an unknown (all-zero) MAC source address (e.g., IGMP Proxy Queriers [RFC4605]), where the source at L2 can not be determined at the Receiver. These packets need to be silently discarded, which may prevent running the associated services on the Receiver.
カプセル化にMAC/NPAソースアドレスが含まれている場合、レシーバーにローカルのL2アドレスを破棄するフィルターを使用して、リンクレイヤーで再ブロードキャストパケットをフィルタリングできます。状況によっては、システムは未知の（全ゼロ）MACソースアドレス（IGMPプロキシクエリエ[RFC4605]など）でパケットを送信できます。ここでは、L2のソースを受信機で決定できません。これらのパケットは静かに廃棄する必要があります。これにより、レシーバーで関連するサービスの実行が妨げられます。
Some encapsulation formats also do not include an MAC/NPA source address (Table 1). Multicast packets may therefore alternatively be discarded at the IP layer if their IP source address matches a local IP address (or address range). Systems can send packets with an all-zero IP source address (e.g., BOOTP (bootstrap protocol) [RFC951], DHCP [RFC2131] and ND [RFC2461]), where the source at L3 can not be determined at the Receiver these packets need to be silently discarded. This may prevent running the associated services at a Receiver, e.g., participation in IPv6 Duplicate Address Detection or running a DHCP server.
一部のカプセル化形式には、MAC/NPAソースアドレスも含まれていません（表1）。したがって、マルチキャストパケットは、IPソースアドレスがローカルIPアドレス（またはアドレス範囲）と一致する場合、IPレイヤーに代わりに破棄される場合があります。システムは、全ゼロのIPソースアドレス（例：BOOTP（BOOTSTRAPプロトコル）[RFC951]、DHCP [RFC2131]、ND [RFC2461]）でパケットを送信できます。静かに捨てられる。これにより、関連するサービスを受信機で実行するのが防止される場合があります。たとえば、IPv6の複製アドレスの検出やDHCPサーバーの実行に参加することができます。
This section considers link layer (L2) support for address resolution in MPEG-2 Networks. It considers two issues: The code-point used at L2 and the efficiency of encapsulation for transmission required to support the AR method. The table below summarizes the options for both MPE ([ETSI-DAT], [ATSC-A90]) and ULE [RFC4326] encapsulations.
このセクションでは、MPEG-2ネットワークのアドレス解像度のリンクレイヤー（L2）サポートを検討します。L2で使用されるコードポイントと、ARメソッドをサポートするために必要な伝送のカプセル化の効率という2つの問題を考慮します。以下の表は、MPE（[ETSI-DAT]、[ATSC-A90]）、ULE [RFC4326]の両方のオプションをまとめたものです。
[RFC4840] describes issues and concerns that may arise when a link can support multiple encapsulations. In particular, it identifies problems that arise when end hosts that belong to the same IP network employ different incompatible encapsulation methods. An Encapsulator must therefore use only one method (e.g., ULE or MPE) to support a single IP network (i.e., set of IPv4 systems sharing the same subnet broadcast address or same IPv6 prefix). All Receivers in an IP network must receive all IP packets that use a broadcast (directed to all systems in the IP network) or a local-scope multicast address (Section 3). Packets with these addresses are used by many IP-based protocols including service discovery, IP AR, and routing protocols. Systems that fail to receive these packets can suffer connectivity failure or incorrect behaviour (e.g., they may be unable to participate in IP-based discovery, configuration, routing, and announcement protocols). Consistent delivery can be ensured by transmitting link-local multicast or broadcast packets using the same Stream that is used for unicast packets directed to this network. A Receiver could simultaneously use more than one L2 AR mechanism. This presents a potential conflict when the Receiver receives two different bindings for the same identifier. When multiple systems advertise AR bindings for the same identifiers (e.g., Encapsulators), they must ensure that the advertised information is consistent. Conflicts may also arise when L2 protocols duplicate the functions of IP-based AR mechanisms.
[RFC4840]は、リンクが複数のカプセルをサポートできる場合に発生する可能性のある問題と懸念を説明しています。特に、同じIPネットワークに属するエンドホストが異なる互換性のないカプセル化方法を採用している場合に発生する問題を特定します。したがって、カプセレータは、単一のIPネットワーク（つまり、同じサブネットブロードキャストアドレスまたは同じIPv6プレフィックスを共有するIPv4システムのセット）をサポートするために、1つのメソッド（ULEまたはMPEなど）のみを使用する必要があります。IPネットワーク内のすべての受信機は、ブロードキャスト（IPネットワーク内のすべてのシステムに向けられた）またはローカルスコープマルチキャストアドレス（セクション3）を使用するすべてのIPパケットを受信する必要があります。これらのアドレスを備えたパケットは、サービス発見、IP AR、ルーティングプロトコルなど、多くのIPベースのプロトコルで使用されます。これらのパケットを受信できないシステムは、接続障害または誤った動作に苦しむ可能性があります（たとえば、IPベースの発見、構成、ルーティング、およびアナウンスプロトコルに参加できない場合があります）。このネットワークに向けられたユニキャストパケットに使用される同じストリームを使用して、リンクローカルマルチキャストまたはブロードキャストパケットを送信することにより、一貫した配信を保証できます。受信者は、同時に複数のL2 ARメカニズムを使用できます。これは、レシーバーが同じ識別子に対して2つの異なるバインディングを受信すると、潜在的な競合を示します。複数のシステムが同じ識別子（例：カプセルター）にARバインディングを宣伝する場合、宣伝された情報が一貫していることを確認する必要があります。L2プロトコルがIPベースのARメカニズムの機能を複製すると、競合が発生する場合があります。
In ULE, the bridging format may be used in combination with the normal mode to address packets to a Receiver (all ULE Receivers are required to implement both methods). Frames carrying IP packets using the ULE Bridging mode, that have a destination address corresponding to the MAC address of the Receiver and have an IP address corresponding to a Receiver interface, will be delivered to the IP stack of the Receiver. All bridged IP multicast and broadcast frames will also be copied to the IP stack of the Receiver.
ULEでは、ブリッジング形式を通常のモードと組み合わせて使用して、レシーバーへのパケットをアドレス指定できます（両方の方法を実装するには、すべてのULEレシーバーが必要です）。ULEブリッジングモードを使用してIPパケットを運ぶフレームは、受信機のMACアドレスに対応する宛先アドレスを持ち、受信機インターフェイスに対応するIPアドレスを持つフレームがレシーバーのIPスタックに配信されます。すべてのブリッジ付きIPマルチキャストおよびブロードキャストフレームも、受信機のIPスタックにコピーされます。
Receivers must filter (discard) frames that are received with a source address that matches an address of the Receiver itself [802.1D]. It must also prevent forwarding frames already sent on a connected network. For each network interface, it must therefore filter received frames where the frame source address matches a unicast destination address associated with a different network interface [802.1D].
受信機は、受信者自体のアドレスと一致するソースアドレスで受信されるフレームをフィルタリングする必要があります[802.1d]。また、接続されたネットワークですでに送信された転送フレームを防ぐ必要があります。したがって、各ネットワークインターフェイスについて、フレームソースアドレスが異なるネットワークインターフェイス[802.1d]に関連付けられたユニキャスト宛先アドレスと一致する受信したフレームをフィルタリングする必要があります。
+-------------------------------+--------+----------------------+
| | PDU |L2 Frame Header Fields|
| L2 Encapsulation |overhead+----------------------+
| |[bytes] |src mac|dst mac| type |
+-------------------------------+--------+-------+-------+------+
|6.1 ULE without dst MAC address| 8 | - | - | x |
|6.2 ULE with dst MAC address | 14 | - | x | x |
|6.3 MPE without LLC/SNAP | 16 | - | x | - |
|6.4 MPE with LLC/SNAP | 24 | - | x | x |
|6.5 ULE with Bridging extension| 22 | x | x | x |
|6.6 ULE with Bridging & NPA | 28 | x | x | x |
|6.7 MPE with LLC/SNAP&Bridging | 38 | x | x | x |
+-------------------------------+--------+-------+-------+------+
Table 1: L2 Support and Overhead (x =supported, - =not supported)
The remainder of the section describes IETF-specified AR methods for use with these encapsulation formats. Most of these methods rely on bidirectional communications (see Sections 5.1, 5.2, and 5.3 for a discussion of this).
セクションの残りの部分では、これらのカプセル化形式で使用するIETF指定ARメソッドについて説明します。これらの方法のほとんどは、双方向通信に依存しています（これについての議論については、セクション5.1、5.2、および5.3を参照）。
The ULE encapsulation supports a mode (D=1) where the MAC/NPA address is not present in the encapsulated frame. This mode may be used with both IPv4 and IPv6. When used, the Receiver is expected to perform L3 filtering of packets based on their IP destination address [RFC4326]. This requires careful consideration of the network topology when a Receiver is an IP router, or delivers data to an IP router (a simple case where this is permitted arises in the connection of stub networks at a Receiver that have no connectivity to other networks). Since there is no MAC/NPA address in the SNDU, ARP and the ND protocol are not required for AR.
ULEカプセル化は、カプセル化されたフレームにMAC/NPAアドレスが存在しないモード（d = 1）をサポートします。このモードは、IPv4とIPv6の両方で使用できます。使用すると、受信機はIP宛先アドレス[RFC4326]に基づいてパケットのL3フィルタリングを実行することが期待されます。これには、受信機がIPルーターである場合、ネットワークトポロジを慎重に検討するか、IPルーターにデータを配信する必要があります（これが許可される単純な場合、他のネットワークに接続されていないレシーバーでのスタブネットワークの接続で発生します）。SNDUにはMAC/NPAアドレスがないため、ARにはARPとNDプロトコルは必要ありません。
IPv6 systems can automatically configure their IPv6 network address based upon a local MAC address [RFC2462]. To use auto-configuration, the IP driver at the Receiver may need to access the MAC/NPA address of the receiving interface, even though this value is not being used to filter received SNDUs.
IPv6システムは、ローカルMACアドレス[RFC2462]に基づいて、IPv6ネットワークアドレスを自動的に構成できます。自動構成を使用するには、受信されたSNDUをフィルタリングするためにこの値が使用されていない場合でも、受信者のIPドライバーは受信インターフェイスのMAC/NPAアドレスにアクセスする必要がある場合があります。
Even when not used for AR, the ND protocol may still be required to support DAD, and other IPv6 network-layer functions. This protocol uses a block of IPv6 multicast addresses, which need to be carried by the L2 network. However, since this encapsulation format does not provide a MAC source address, there are topologies (e.g., Section 5.6.1) where a system can not differentiate DAD packets that were originally sent by itself and were re-broadcast, from those that may have been sent by another system with the same L3 address. Therefore, DAD can not be used with this encapsulation format in topologies where this L2 forwarding may occur.
ARに使用されていない場合でも、NDプロトコルは依然としてDAD、および他のIPv6ネットワーク層機能をサポートする必要がある場合があります。このプロトコルでは、L2ネットワークが携帯する必要があるIPv6マルチキャストアドレスのブロックを使用しています。ただし、このカプセル化形式はMACソースアドレスを提供しないため、システムが元々送信され、再ブロードキャストされたパパパケットを区別できないトポロジ（セクション5.6.1など）があります。同じL3アドレスを持つ別のシステムから送信されました。したがって、このL2転送が発生する可能性のあるトポロジーでは、このカプセル化形式ではお父さんを使用できません。
The IPv4 Address Resolution Protocol (ARP) [RFC826] is identified by an IEEE EtherType and may be used over ULE [RFC4326]. Although no MAC source address is present in the ULE SNDU, the ARP protocol still communicates the source MAC (hardware) address in the ARP record payload of any query messages that it generates.
IPv4アドレス解像度プロトコル（ARP）[RFC826]は、IEEE EtherTypeによって識別され、ULE [RFC4326]で使用できます。ULE SNDUにはMACソースアドレスは存在しませんが、ARPプロトコルは、生成するクエリメッセージのARPレコードペイロードのソースMAC（ハードウェア）アドレスを引き続き伝えます。
The IPv6 ND protocol is supported. The protocol uses a block of IPv6 multicast addresses, which need to be carried by the L2 network. The protocol uses a block of IPv6 multicast addresses, which need to be carried by the L2 network. However, since this encapsulation format does not provide a MAC source address, there are topologies (e.g., Section 5.6.1) where a system can not differentiate DAD packets that were originally sent by itself and were re-broadcast, from those that may have been sent by another system with the same L3 address. Therefore, DAD can not be used with this encapsulation format in topologies where this L2 forwarding may occur.
IPv6 NDプロトコルがサポートされています。このプロトコルは、L2ネットワークが携帯する必要があるIPv6マルチキャストアドレスのブロックを使用します。このプロトコルは、L2ネットワークが携帯する必要があるIPv6マルチキャストアドレスのブロックを使用します。ただし、このカプセル化形式はMACソースアドレスを提供しないため、システムが元々送信され、再ブロードキャストされたパパパケットを区別できないトポロジ（セクション5.6.1など）があります。同じL3アドレスを持つ別のシステムから送信されました。したがって、このL2転送が発生する可能性のあるトポロジーでは、このカプセル化形式ではお父さんを使用できません。
This is the default (and sometimes only) mode specified by most MPE Encapsulators. MPE does not provide an EtherType field and therefore can not support the Address Resolution Protocol (ARP) [RFC826].
これは、ほとんどのMPEカプセル因子によって指定されたデフォルト（および場合によってはみの）モードです。MPEはEtherTypeフィールドを提供しないため、アドレス解像度プロトコル（ARP）[RFC826]をサポートできません。
IPv6 is not supported in this encapsulation format, and therefore it is not appropriate to consider the ND protocol.
IPv6はこのカプセル化形式ではサポートされていないため、NDプロトコルを考慮することは適切ではありません。
The LLC/SNAP (Sub-Network Access Protocol) format of MPE provides an EtherType field and therefore may support ARP [RFC826]. There is no specification to define how this is performed. No MAC source address is present in the SNDU, although the protocol communicates the source MAC address in the ARP record payload of any query messages that it generates.
MPEのLLC/SNAP（サブネットワークアクセスプロトコル）形式は、EtherTypeフィールドを提供するため、ARP [RFC826]をサポートする場合があります。これがどのように実行されるかを定義する仕様はありません。SNDUにはMACソースアドレスはありませんが、プロトコルは、生成するクエリメッセージのARPレコードペイロードのソースMACアドレスを伝えます。
The IPv6 ND protocol is supported using The LLC/SNAP format of MPE. This requires specific multicast addresses to be carried by the L2 network. The IPv6 ND protocol is supported. The protocol uses a block of IPv6 multicast addresses, which need to be carried by the L2 network. However, since this encapsulation format does not provide a MAC source address, there are topologies (e.g., Section 5.6.1) where a system can not differentiate DAD packets that were originally sent by itself and were re-broadcast, from those that may have been sent by another system with the same L3 address. Therefore, DAD can not be used with this encapsulation format in topologies where this L2 forwarding may occur.
IPv6 NDプロトコルは、MPEのLLC/SNAP形式を使用してサポートされています。これには、L2ネットワークが携帯する特定のマルチキャストアドレスが必要です。IPv6 NDプロトコルがサポートされています。このプロトコルは、L2ネットワークが携帯する必要があるIPv6マルチキャストアドレスのブロックを使用します。ただし、このカプセル化形式はMACソースアドレスを提供しないため、システムが元々送信され、再ブロードキャストされたパパパケットを区別できないトポロジ（セクション5.6.1など）があります。同じL3アドレスを持つ別のシステムから送信されました。したがって、このL2転送が発生する可能性のあるトポロジーでは、このカプセル化形式ではお父さんを使用できません。
The ULE encapsulation supports a bridging extension header that supplies both a source and destination MAC address. This can be used without an NPA address (D=1). When no other Extension Headers precede this Extension, the MAC destination address has the same position in the ULE SNDU as that used for an NPA destination address. The Receiver may optionally be configured so that the MAC destination address value is identical to a Receiver NPA address.
ULEカプセル化は、ソースと宛先MACアドレスの両方を提供するブリッジングエクステンションヘッダーをサポートしています。これは、NPAアドレスなしで使用できます（d = 1）。他の拡張ヘッダーがこの拡張機能に先行していない場合、MAC宛先アドレスはULE SNDUでNPA宛先アドレスに使用されているものと同じ位置を持っています。MAC宛先アドレス値がレシーバーNPAアドレスと同一になるように、受信機をオプションで構成することができます。
At the Encapsulator, the ULE MAC/NPA destination address is determined by a L2 forwarding decision. Received frames may be forwarded or may be addressed to the Receiver itself. As in other L2 LANs, the Receiver may choose to filter received frames based on a configured MAC destination address filter. ARP and ND messages may be carried within a PDU that is bridged by this encapsulation format. Where the topology may result in subsequent reception of re-broadcast copies of multicast frames that were originally sent by a Receiver (e.g., Section 5.6.1), the system must discard frames that are received with a source address that it used in frames sent from the same interface [802.1D]. This prevents duplication on the bridged network (e.g., this would otherwise invoke DAD).
カプセレータでは、ULE MAC/NPA宛先アドレスはL2転送決定によって決定されます。受信したフレームは転送されるか、受信機自体に宛てられている場合があります。他のL2 LANと同様に、受信機は、構成されたMac宛先アドレスフィルターに基づいて受信フレームをフィルタリングすることを選択できます。ARPおよびNDメッセージは、このカプセル化形式によって架かるPDU内で運ばれる場合があります。トポロジが、元々受信者によって送信されたマルチキャストフレームの再ブロードキャストコピーのその後の受信をもたらす可能性がある場合（例：セクション5.6.1）、システムは送信されたフレームで使用されたソースアドレスで受信したフレームを破棄する必要があります。同じインターフェイスから[802.1d]。これにより、ブリッジされたネットワークの重複が防止されます（例えば、これはそれ以外の場合はパパを呼び起こすでしょう）。
The combination of an NPA address (D=0) and a bridging extension header are allowed in ULE. This SNDU format supplies both a source and destination MAC address and a NPA destination address (i.e., Receiver MAC/NPA address).
NPAアドレス（d = 0）とブリッジングエクステンションヘッダーの組み合わせがULEで許可されています。このSNDU形式は、ソースと宛先MACアドレスとNPA宛先アドレス（つまり、受信者MAC/NPAアドレス）の両方を提供します。
At the Encapsulator, the value of the ULE MAC/NPA destination address is determined by a L2 forwarding decision. At the Receiver, frames may be forwarded or may be addressed to the Receiver itself. As in other L2 LANs, the Receiver may choose to filter received frames based on a configured MAC destination address filter. ARP and ND messages may be carried within a PDU that is bridged by this encapsulation format. Where the topology may result in the subsequent reception of re-broadcast copies of multicast frames, that were originally sent by a Receiver (e.g., Section 5.6.1), the system must discard frames that are received with a source address that it used in frames sent from the same interface [802.1D]. This prevents duplication on the bridged network (e.g., this would otherwise invoke DAD).
カプセレータでは、ULE MAC/NPA宛先アドレスの値は、L2転送決定によって決定されます。受信機では、フレームが転送されるか、受信機自体に宛てられてもよい場合があります。他のL2 LANと同様に、受信機は、構成されたMac宛先アドレスフィルターに基づいて受信フレームをフィルタリングすることを選択できます。ARPおよびNDメッセージは、このカプセル化形式によって架かるPDU内で運ばれる場合があります。トポロジが、もともと受信機によって送信されたマルチキャストフレームの再ブロードキャストコピーのその後の受信をもたらす可能性がある場合（例：セクション5.6.1）、システムは、使用したソースアドレスで受信したフレームを破棄する必要があります。同じインターフェイス[802.1d]から送信されたフレーム。これにより、ブリッジされたネットワークの重複が防止されます（例えば、これはそれ以外の場合はパパを呼び起こすでしょう）。
The LLC/SNAP format MPE frames may optionally support an IEEE bridging header [LLC]. This header supplies both a source and destination MAC address, at the expense of larger encapsulation overhead. The format defines two MAC destination addresses, one associated with the MPE SNDU (i.e., Receiver MAC address) and one with the bridged MAC frame (i.e., the MAC address of the intended recipient in the remote LAN).
LLC/SNAP形式のMPEフレームは、オプションでIEEEブリッジングヘッダー[LLC]をサポートする場合があります。このヘッダーは、より大きなカプセル化オーバーヘッドを犠牲にして、ソースと宛先MACアドレスの両方を提供します。この形式は、MPE SNDU（つまり、レシーバーMACアドレス）に関連付けられている2つのMAC宛先アドレスと、ブリッジ付きMACフレーム（つまり、リモートLANの意図した受信者のMACアドレス）を備えた2つのMAC宛先アドレスを定義します。
At the Encapsulator, the MPE MAC destination address is determined by a L2 forwarding decision. There is currently no formal description of the Receiver processing for this encapsulation format. A Receiver may forward frames or they may be addressed to the Receiver itself. As in other L2 LANs, the Receiver may choose to filter received frames based on a configured MAC destination address filter. ARP and ND messages may be carried within a PDU that is bridged by this encapsulation format. The MPE MAC destination address is determined by a L2 forwarding decision. Where the topology may result in a subsequent reception of re-broadcast copies of multicast frames, that were originally sent by a Receiver (e.g., Section 5.6.1), the system must discard frames that are received with a source address that it used in frames sent from the same interface [802.1D]. This prevents duplication on the bridged network (e.g., this would otherwise invoke DAD).
カプセレータでは、MPE MAC宛先アドレスはL2転送決定によって決定されます。現在、このカプセル化形式の受信機処理の正式な説明はありません。受信者は、フレームを転送する場合や、レシーバー自体に宛てられてもよい場合があります。他のL2 LANと同様に、受信機は、構成されたMac宛先アドレスフィルターに基づいて受信フレームをフィルタリングすることを選択できます。ARPおよびNDメッセージは、このカプセル化形式によって架かるPDU内で運ばれる場合があります。MPE MAC宛先アドレスは、L2転送決定によって決定されます。トポロジが、もともとレシーバー（例えば、セクション5.6.1）によって送信されたマルチキャストフレームの再broadcastコピーのその後の受信をもたらす可能性がある場合、システムは、使用したソースアドレスで受信したフレームを破棄する必要があります。同じインターフェイス[802.1d]から送信されたフレーム。これにより、ブリッジされたネットワークの重複が防止されます（例えば、これはそれ以外の場合はパパを呼び起こすでしょう）。
This document describes addressing and address resolution issues for IP protocols over MPEG-2 transmission networks using both wired and wireless technologies. A number of specific IETF protocols are discussed along with their expected behaviour over MPEG-2 transmission networks. Recommendations for their usage are provided.
このドキュメントでは、有線技術とワイヤレステクノロジーの両方を使用したMPEG-2伝送ネットワークを介したIPプロトコルの解決策の対処と対処に関する問題について説明します。多くの特定のIETFプロトコルについて、MPEG-2伝送ネットワークを介した予想される動作とともに説明されています。使用に関する推奨事項が提供されます。
There is no single common approach used in all MPEG-2 Networks. A static binding may be configured for IP addresses and PIDs (as in some cable networks). In broadcast networks, this information is normally provided by the Encapsulator/Multiplexor and carried in signalling tables (e.g., AIT in MHP, the IP Notification Table, INT, of DVB and the DVB-RCS Multicast Mapping Table, and MMT). This document has reviewed the status of these current address resolution mechanisms in MPEG-2 transmission networks and defined their usage.
すべてのMPEG-2ネットワークで使用される単一の一般的なアプローチはありません。静的バインディングは、IPアドレスとPID（一部のケーブルネットワークのように）に構成される場合があります。ブロードキャストネットワークでは、この情報は通常、エンカプセーター/マルチプレクサーによって提供され、シグナリングテーブル（例：MHPのAIT、DVBおよびDVB-RCSマルチキャストマッピングテーブル、およびMMT）でAITに携帯されています。このドキュメントでは、MPEG-2伝送ネットワークにおけるこれらの現在のアドレス解像度メカニズムのステータスを確認し、それらの使用法を定義しました。
The document also considers a unified IP-based method for AR that could be independent of the physical layer, but does not define a new protocol. It examines the design criteria for a method, with recommendations to ensure scalability and improve support for the IP protocol stack.
このドキュメントでは、物理層とは独立しているが新しいプロトコルを定義しないARの統一されたIPベースの方法も考慮しています。スケーラビリティを確保し、IPプロトコルスタックのサポートを改善するための推奨事項を備えたメソッドの設計基準を調べます。
The normal security issues relating to the use of wireless links for transmission of Internet traffic should be considered.
インターネットトラフィックの送信のためのワイヤレスリンクの使用に関する通常のセキュリティの問題を考慮する必要があります。
L2 signalling in MPEG-2 transmission networks is currently provided by (periodic) broadcasting of information in the control plane using PSI/SI tables (Section 4). A loss or modification of the SI information may result in an inability to identify the TS Logical Channel (PID) that is used for a service. This will prevent reception of the intended IP packet stream.
MPEG-2伝送ネットワークのL2シグナリングは、現在、PSI/SIテーブルを使用してコントロールプレーンの情報の（周期的な）ブロードキャストによって提供されています（セクション4）。SI情報の損失または変更により、サービスに使用されるTS論理チャネル（PID）を識別できない場合があります。これにより、意図したIPパケットストリームの受信が妨げられます。
There are known security issues relating to the use of unsecured address resolution [RFC3756]. Readers are also referred to the known security issues when mapping IP addresses to MAC/NPA addresses using ARP [RFC826] and ND [RFC2461]. It is recommended that AR protocols support authentication of the source of AR messages and the integrity of the AR information, this avoids known security vulnerabilities resulting from insertion of unauthorized AR messages within a L2 infrastructure. For IPv6, the SEND protocol [RFC3971] may be used in place of ND. This defines security mechanisms that can protect AR.
無担保住所解決の使用に関する既知のセキュリティ問題[RFC3756]があります。読者は、ARP [RFC826]およびND [RFC2461]を使用してMAC/NPAアドレスにIPアドレスをマッピングする場合、既知のセキュリティ問題についても参照されます。ARプロトコルは、ARメッセージのソースの認証とAR情報の整合性をサポートすることをお勧めします。これにより、L2インフラストラクチャ内の不正なARメッセージの挿入に起因する既知のセキュリティの脆弱性が回避されます。IPv6の場合、NDの代わりに送信プロトコル[RFC3971]を使用できます。これは、ARを保護できるセキュリティメカニズムを定義します。
AR protocols can also be protected by the use of L2 security methods (e.g., Encryption of the ULE SNDU [IPDVB-SEC]). When these methods are used, the security of ARP and ND can be comparable to that of a private LAN: A Receiver will only accept ARP or ND transmissions from the set of peer senders that share a common group encryption and common group authentication key provided by the L2 key management.
ARプロトコルは、L2セキュリティメソッド（ULE SNDUの暗号化[IPDVB-SEC]）の使用によって保護することもできます。これらのメソッドを使用すると、ARPとNDのセキュリティはプライベートLANのセキュリティに匹敵する可能性があります。レシーバーは、共通のグループ暗号化と共通グループ認証キーを共有するピアセンダーのセットからのARPまたはND送信のみを受け入れます。L2キー管理。
AR Servers (Section 5.4) are susceptible to the same kind of security issues as end hosts using unsecured AR. These issues include hijacking traffic and denial-of-service within the subnet. Malicious nodes within the subnet can take advantage of this property, and hijack traffic. In addition, an AR Server is essentially a legitimate man-in-the-middle, which implies that there is a need to distinguish such proxies from unwanted man-in-the-middle attackers. This document does not introduce any new mechanisms for the protection of these AR functions (e.g., authenticating servers, or defining AR Servers that interoperate with the SEND protocol [SP-ND]).
ARサーバー（セクション5.4）は、無担保ARを使用してエンドホストと同じ種類のセキュリティ問題を受けやすいです。これらの問題には、サブネット内のトラフィックとサービス拒否のハイジャックが含まれます。サブネット内の悪意のあるノードは、このプロパティを活用し、トラフィックをハイジャックできます。さらに、ARサーバーは本質的に正当な中間の男であり、これはそのようなプロキシを不要な中間の攻撃者と区別する必要があることを意味します。このドキュメントでは、これらのAR関数を保護するための新しいメカニズムを導入しません（たとえば、サーバーの認証、または送信プロトコルと相互操作するARサーバーの定義[SP-ND]）。
The authors wish to thank the IPDVB WG members for their inputs and in particular, Rod Walsh, Jun Takei, and Michael Mercurio. The authors also acknowledge the support of the European Space Agency. Martin Stiemerling contributed descriptions of scenarios, configuration, and provided extensive proof reading. Hidetaka Izumiyama contributed on UDLR and IPv6 issues. A number of issues discussed in the UDLR working group have also provided valuable inputs to this document (summarized in "Experiments with RFC 3077", July 2003).
著者は、IPDVB WGメンバーの入力、特にRod Walsh、Jun Takei、Michael Mercurioに感謝したいと考えています。著者はまた、欧州宇宙機関の支援を認めています。Martin Stiemerlingは、シナリオ、構成の説明を提供し、広範な証拠の読み取り値を提供しました。Hidetaka Izumiyamaは、UDLRおよびIPv6の問題に貢献しました。UDLRワーキンググループで議論されている多くの問題も、このドキュメントに貴重なインプットを提供しています（2003年7月、「RFC 3077の実験」に要約されています）。
[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting", v1.3.1, European Telecommunications Standards Institute (ETSI), May 2003.
[ETSI-DAT] EN 301 192、「データブロードキャストの仕様」、v1.3.1、欧州通信標準研究所（ETSI）、2003年5月。
[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-SI] EN 300 468, "Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB systems", v1.7.1, European Telecommunications Standards Institute (ETSI), December 2005.
[ETSI-SI] EN 300 468、「デジタルビデオブロードキャスト（DVB）; DVBシステムのサービス情報の仕様（SI）、v1.7.1、欧州通信標準研究所（ETSI）、2005年12月。
[ISO-MPEG2] ISO/IEC IS 13818-1, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", International Standards Organization (ISO), 2000.
[ISO-MPEG2] ISO/IECは13818-1、「情報技術 - 移動写真と関連するオーディオ情報の一般的なコーディング - パート1：システム」、国際標準組織（ISO）、2000。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982.
[RFC826] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレス」、STD 37、RFC 826、1982年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] DROMS、R。、「動的ホスト構成プロトコル」、RFC 2131、1997年3月。
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. Zhang, "A Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, March 2001.
[RFC3077] Duros、E.、Dabbous、W.、Izumiyama、H.、Fujii、N。、およびY. Zhang、「単方向リンクのためのリンク層トンネルメカニズム」、RFC 3077、2001年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] DROMS、R.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] DROMS、R。、「IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス」、RFC 3736、2004年4月。
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional Lightweight Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326, December 2005.
[RFC4326] Fairhurst、G。およびB. Collini-Nocker、「MPEG-2トランスポートストリーム（TS）を介したIPデータグラムの送信のための単方向の軽量カプセル化（ULE）」、RFC 4326、2005年12月。
[802.1D] IEEE 802.1D, "IEEE Standard for Local and Metropolitan Area Networks: Media Access Control (MAC) Bridges", IEEE, 2004.
[802.1d] IEEE 802.1d、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準：メディアアクセス制御（MAC）ブリッジ」、IEEE、2004。
[802.3] IEEE 802.3, "Local and metropolitan area networks-Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Computer Society, (also ISO/IEC 8802-3), 2002.
[802.3] IEEE 802.3、「ローカルおよびメトロポリタンエリアネットワーク固有の要件パート3：衝突検出を備えたキャリアセンスマルチアクセス（CSMA/CD）アクセス方法と物理層の仕様」、IEEEコンピューターソサエティ（ISO/IEC 8802-3）、2002年。
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC] A/53C、「ATSC Digital Television Standard」、Advanced Television Systems Committee（ATSC）、Doc。A/53C、2004年。
[ATSC-A54A] A/54A, "Guide to the use of the ATSC Digital Television Standard", Advanced Television Systems Committee (ATSC), Doc. A/54A, 2003.
[ATSC-A54A] A/54A、「ATSCデジタルテレビ標準の使用に関するガイド」、Advanced Television Systems Committee（ATSC）、Doc。A/54A、2003年。
[ATSC-A90] A/90, "ATSC Data Broadcast Standard", Advanced Television Systems Committee (ATSC), Doc. A/90, 2000.
[ATSC-A90] A/90、「ATSC Data Broadcast Standard」、Advanced Television Systems Committee（ATSC）、Doc。A/90、2000。
[ATSC-A92] A/92, "Delivery of IP Multicast Sessions over ATSC Data Broadcast", Advanced Television Systems Committee (ATSC), Doc. A/92, 2002.
[ATSC-A92] A/92、「ATSCデータブロードキャストを介したIPマルチキャストセッションの配信」、Advanced Television Systems Committee（ATSC）、Doc。A/92、2002。
[DOCSIS] "Data-Over-Cable Service Interface Specifications, DOCSIS 2.0, Radio Frequency Interface Specification", CableLabs, document CM-SP-RFIv2.0-I10-051209, 2005.
[docsis]「データオーバーサービスインターフェイス仕様、Docsis 2.0、無線周波数インターフェイス仕様」、CableLabs、Document CM-SP-RFIV2.0-I10-051209、2005。
[DVB] Digital Video Broadcasting (DVB) Project. http://www.dvb.org.
[DVB]デジタルビデオ放送（DVB）プロジェクト。http://www.dvb.org。
[ETSI-DVBS] EN 301 421,"Digital Video Broadcasting (DVB); Modulation and Coding for DBS satellite systems at 11/12 GHz", European Telecommunications Standards Institute (ETSI).
[ETSI-DVBS] EN 301 421、「デジタルビデオ放送（DVB）; 11/12 GHzでのDBS衛星システムの変調とコーディング」、欧州通信標準研究所（ETSI）。
[ETSI-RCS] EN 301 790, "Digital Video Broadcasting (DVB); Interaction channel for satellite distribution Systems", European Telecommunications Standards Institute (ETSI).
[ETSI-RCS] EN 301 790、「デジタルビデオブロードキャスト（DVB）;衛星配信システム用の相互作用チャネル」、欧州通信標準研究所（ETSI）。
[ETSI-SI1] TR 101 162, "Digital Video Broadcasting (DVB); Allocation of Service Information (SI) codes for DVB systems", European Telecommunications Standards Institute (ETSI).
[ETSI-SI1] TR 101 162、「デジタルビデオ放送（DVB）、DVBシステムのサービス情報の割り当て（SI）コード」、欧州通信基準研究所（ETSI）。
[IPDVB-SEC] H. Cruickshank, S. Iyengar, L. Duquerroy, P. Pillai, "Security requirements for the Unidirectional Lightweight Encapsulation (ULE) protocol", Work in Progress, May 2007.
[IPDVB-Sec] H. Cruickshank、S。Iyengar、L。Duquerroy、P。Pillai、「単方向の軽量カプセル化（ULE）プロトコルのセキュリティ要件」、2007年5月、進行中の作業。
[ISO-DSMCC] ISO/IEC IS 13818-6, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 6: Extensions for DSM-CC is a full software implementation", International Standards Organization (ISO), 2002.
[ISO-DSMCC] ISO/IECは13818-6です。、2002年。
[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 Organization (ISO), 1998.
[LLC] ISO/IEC 8802.2、「情報技術、システム間の通信と情報交換、ローカルおよび大都市圏ネットワーク、特定の要件、パート2：論理リンク制御」、国際標準組織（ISO）、1998。
[MMT] "SatLabs System Recommendations, Part 1, General Specifications", Version 2.0, SatLabs Forum, 2006. http://satlabs.org/pdf/ SatLabs_System_Recommendations_v2.0_general.pdf.
[MMT]「Satlabsシステムの推奨事項、パート1、一般仕様」、バージョン2.0、Satlabs Forum、2006。http：//satlabs.org/pdf/ satlabs_system_recommendations_v2.0_general.pdf。
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[RFC951] Croft、W。およびJ. Gilmore、「Bootstrap Protocol」、RFC 951、1985年9月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365] Meyer、D。、「管理上スコープIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC2375] Hinden、R。およびS. Deering、「IPv6マルチキャストアドレスの割り当て」、RFC 2375、1998年7月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[RFC3256] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option", RFC 3256, April 2002.
[RFC3256]ジョーンズ、D。およびR.創傷、「DocSIS（データオーバーサービスインターフェイス仕様）デバイスクラスDHCP（ダイナミックホスト構成プロトコル）リレーエージェント情報サブオプション」、RFC 3256、2002年4月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. Sooriyabandara, "TCP Performance Implications of Network Path Asymmetry", BCP 69, RFC 3449, December 2002.
[RFC3449] Balakrishnan、H.、Padmanabhan、V.、Fairhurst、G。、およびM. Sooriyabandara、「ネットワークパス非対称性のTCPパフォーマンスの影響」、BCP 69、RFC 3449、2002年12月。
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., Handley, M., and J. Crowcroft, "Layered Coding Transport (LCT) Building Block", RFC 3451, December 2002.
[RFC3451] Luby、M.、Gemmell、J.、Vicisano、L.、Rizzo、L.、Handley、M。、およびJ. Crowcroft、「層状コーディング輸送（LCT）ビルディングブロック」、RFC 3451、2002年12月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569] Bhattacharyya、S。、「ソース固有のマルチキャスト（SSM）の概要」、RFC 3569、2003年7月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trustモデルと脅威」、RFC 3756、2004年5月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738] Luby、M。およびV. Goyal、「波と方程式ベースのレート制御（WEBRC）ビルディングブロック」、RFC 3738、2004年4月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819] Karn、P.、Bormann、C.、Fairhurst、G.、Grossman、D.、Ludwig、R.、Mahdavi、J.、Montenegro、G.、Touch、J.、およびL. Wood、「アドバイス」アドバイスインターネットサブネットワークデザイナー向け」、BCP 89、RFC 3819、2004年7月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（Send）」、RFC 3971、2005年3月。
[RFC4259] Weis, B., "The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4359, January 2006.
[RFC4259] Weis、B。、「セキュリティペイロード（ESP）および認証ヘッダー（AH）のカプセル化内でのRSA/SHA-1シグネチャの使用」、RFC 4359、2006年1月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.1」、RFC 4346、2006年4月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389] Thaler、D.、Talwar、M。、およびC. Patel、「Neighbor Discovery Proxies（ND Proxy）」、RFC 4389、2006年4月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）：プロトコル仕様（改訂）」、RFC 4601、2006年8月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4605] Fenner、B.、He、H.、Haberman、B。、およびH. Sandick、「インターネットグループ管理プロトコル（IGMP） /マルチキャストリスナーディスカバリー（MLD）ベースのマルチキャスト転送（「IGMP / MLDプロキシ」）"、RFC 4605、2006年8月。
[RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and J. Palet, "ISP IPv6 Deployment Scenarios in Broadband Access Networks", RFC 4779, January 2007.
[RFC4779] Asadullah、S.、Ahmed、A.、Popoviciu、C.、Savola、P。、およびJ. Palet、「ブロードバンドアクセスネットワークのISP IPv6展開シナリオ」、RFC 4779、2007年1月。
[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple Encapsulation Methods Considered Harmful", RFC 4840, April 2007.
[RFC4840] Aboba、B.、Davies、E。、およびD. Thaler、「有害と見なされる複数のカプセル化方法」、RFC 4840、2007年4月。
[SCTE-1] "IP Multicast for Digital MPEG Networks", SCTE DVS 311r6, March 2002.
[SCTE-1]「デジタルMPEGネットワーク用のIPマルチキャスト」、SCTE DVS 311R6、2002年3月。
[SP-ND] Daley, G., "Securing Proxy Neighbour Discovery Problem Statement", Work in Progress, February 2005.
[SP-ND] Daley、G。、「Proxy Neighbor Discovery Problem Statementのセキュアリング」、2005年2月、Work in Progress。
Authors' Addresses
著者のアドレス
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK
ゴッドレッドフェアハースト工科大学アバディーン大学アバディーン大学、AB24 3UE UK
EMail: gorry@erg.abdn.ac.uk
URL: http://www.erg.abdn.ac.uk/users/gorry
Marie-Jose Montpetit Motorola Connected Home Solutions Advanced Technology 55 Hayden Avenue, 3rd Floor Lexington, Massachusetts 02421 USA
Marie-Jose Montpetit Motorola Connected Home Solutions Advanced Technology 55 Hayden Avenue、3階のレキシントン、マサチューセッツ02421 USA
EMail: mmontpetit@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。