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）IETFトラスト（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.
MPEG2 TS仕様ISO / IEC 138181で定義されたカプセル化されたIPデータグラム[RFC4259]、[ISO-MPEG2]を含むオーディオ、ビデオ、およびデータ情報を、含むことができる時分割多重（TDM）ストリームを提供します。 TSパケットとして知られる各レイヤ2（L2）フレームは、4バイトのヘッダと184バイトのペイロードを含んでいます。各TSパケットは、単一のTS MPEG-2 TSパケットヘッダで運ばれる13ビットのパケットID（PID）値によって識別される論理チャネルに関連付けられています。
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).
IPをサポートするL2リンクとしてMPEG-2 TSを利用するために、送信者が特定の送信マルチプレックスとIPアドレスを関連付ける必要があり、マルチプレックス内で、使用される特定のPIDを識別する。この文書では、AR機能このマッピングを呼び出します。いくつかのARスキームにおいて、MPEG-2 TSのアドレス空間は、プラットフォーム[ETSI-DAT]としても知られている論理的コンテキストに細分されます。各プラットフォーム（すなわち、同じPID値を使用する）共通のMPEG-2 TSを共有する別個のコンテキストを持つIPサービスプロバイダを関連付けます。
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受信機は一意的にMPEG-2伝送ネットワーク内のL2ノードを識別するために、添付のネットワークポイント（NPA）[RFC4259]を使用することができます。 NPAの例は、IEEE媒体アクセス制御（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フォワーディングの様々な他の組合せも（直接ブリッジLANセグメントに接続されたIPエンドホストとエンドホストである受信機を含む）MPEG-2リンク上で使用されてもよいです。
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は、IPサブネットワーク（R2、等）内にレイヤ2で各受信機を識別するためにエンカプスレータ（R1）で行われます。
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はまた、フィードルータ（R1）は、レイヤ2（R2など）で下流のルータを識別できるようにするIPサブネットワーク間で行われます。エンカプスレータは、MPEG-2リンク上で送信された各ブリッジPDUと宛先MAC / NPAアドレスを関連付けます。二つの方法は、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サブネットワーク内の宛先（ネクストホップルータ、R2の2B）に対応するMACアドレスです。これは、フィードL2サブネットワーク上に存在するMACアドレスのセットを受信するMPEG-2インターフェースを関連付ける（B2-B4）各受信機を必要とします。 IPベースのトンネルは（UDLR（片方向リンク）の使用を含む[RFC3077]）L2サービスをサポートする場合にも、同様の考慮事項が適用されます。
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.
また、MPEG-2リンク（図2）上の受信L2インターフェイスに関連付けられたMAC / NPAアドレスを含むリンク固有のヘッダを有するPDUをカプセル化する架橋エンカプスレータ（B1）も可能です。この場合、カプセル化されたフレームの宛先MAC / NPAアドレスは、受信機MAC / NPAアドレス（Y）よりもむしろ最終L2宛先のアドレスに設定されています。異なるレベルで、結合ARはまた、R2と宛先L2アドレス2bとを関連付けるためにR1のために必要とされます。ブリッジを使用してサブネットワークにおいて、システムR1及びR2は、通常、（例えば、IPv4アドレス解決プロトコル（ARP）[RFC826]とIPv6近隣探索プロトコル（ND）[RFC2461]）エッジ・ツー・標準IETF定義のARメカニズムを使用します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アドレスを割り当てるために存在する（例えば、ステートレス自動[RFC2461]、DHCP [RFC2131]、DHCPv6の[RFC3315]、およびステートレスDHCPv6の[RFC3736]）。受信機はまた、（例えば、DHCPリレー[RFC3046]を使用して）接続された機器で使用さL3 IPアドレスのリモート構成に参加することができます。
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.
この文書の残りの部分は、対応するTS多重、PID値、MAC / NPAアドレス及び/又はプラットフォームIDとIPアドレスを関連付けるために、現在のメカニズムとそれらの使用を記載しています。アプローチの範囲は、（[RFC2461] ARP [RFC826]とNDを含む）IPレベルでのレイヤ2つの（MPEG-2 SIテーブルを使用して）メカニズム、およびプロトコルを含む、記載されています。これらの機構およびカプセル化方法との間の相互作用と依存関係が記載されています。文書は、提案や新しいプロトコルを定義しますが、電源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]で指定されたアプリケーション情報テーブル。このテーブルは、MPEG-2 TSアドレス解決情報へのIPv4 / IPv6を運ぶことができます。
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 MPEG2規格[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.
DSMCC：デジタルストレージメディアコマンドおよびコントロール[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：衛星を経由してデジタルビデオ放送リターンチャンネル。低コストのレシーバを用いた双方向のIPv4 / IPv6サービス[ETSI-RCS]。
DVB-S: Digital Video Broadcast for Satellite [ETSI-DVBS].
DVBS：衛星用デジタルビデオ放送[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.
カプセル化：TSパケットのストリームとして出力するためのPDUを受信し、（SNDUsとしてここでは知られている）ペイロード単位にこれらをフォーマットするネットワーク装置。
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：マルチメディア・ホーム・プラットフォーム。 （いくつかの場合において）のIPv4 / IPv6サービス[ETSI-MHP]をサポートすることができる統合されたMPEG-2マルチメディア受信機。
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] PID値にIPv4マルチキャストアドレスをマッピング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]。 DSM-CCテーブル部を形成し、PDUをカプセル化する方法。各セクションは、単一のストリーム（TS論理チャネル）を使用して、TSパケットの直列に送信されます。
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards Organization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
MPEG2：Motion Picture Experts Group（MPEG）がで指定された標準のセット、および国際標準化機構（ISO / IEC 113818から1）[ISO-MPEG2]、および（H.220）でITU-Tで標準化さ。
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：添付ファイルのネットワークポイント。レシーバの個々のレシーバまたはグループ[RFC4259]を識別するために使用されるMPEG-2伝送ネットワーク内の6バイトの宛先アドレス（IEEE MACアドレスに似ています）。
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値と各プログラムを関連付けます。テーブルは、$ 000のよく知られた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]。 13ビットのフィールドは、各TSパケットのヘッダで運ば。これは、TS論理チャネルを識別するTSパケットが属する[ISO-MPEG2]。表セクション、または他のペイロードユニットの部分を形成するTSパケットはすべて同じPID値を運ぶ必要があります。すべてのもののPID値はNULL TSパケットはTS多重の固定ビットレートを維持するために導入示します。別のTSを多重化を使用して送信TS論理チャネルのために使用されたPID値の間に必要な関係はありません。
PMT: Program Map Table. An MPEG-2 PSI control table that associates the PID values used by the set of TS Logical Channels/ Streams that comprise a program [ISO-MPEG2]. The PID value used to send the PMT for a specific program is defined by an entry in the PAT.
PMT：プログラムマップテーブル。 TS論理チャネル/プログラム[ISO-MPEG2]を含むストリームのセットによって使用されるPID値を関連付けたMPEG2 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つ以上のエレメンタリストリーム、または特定のMPEG2プログラム、または全トランスポートストリームに関連する個人情報を（すなわち、[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多重で運ばサービスに関する情報を伝えるために使用されます。また、SIテーブルを参照して4つの具体的に特定テーブルセクション構築[ISO-MPEG2]のいずれかに搬送されます。
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表のすべてのセクションは、論理チャネル[ISO-MPEG2単一TSを介して搬送されなければなりません。
SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU：サブネットワークデータユニット。 MPEG-2ペイロード・ユニットとして送信されるカプセル化されたPDU。
Table Section: A Payload Unit carrying all or 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：トランスポートストリーム[ISO-MPEG2]、TSパケットを用いて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
TS論理チャネル：トランスポート・ストリーム論理チャネル。この文書では、この用語は、MPEG2レベル[ISO-MPEG2]のチャネルを識別する。これは、ISO / OSI参照モデルのレベル2に存在します。 TS論理チャネルを介して送信されるすべてのパケットは、（この値は、特定のTSマルチプレックス内で一意である）同じPID値を運びます。用語 "ストリーム" はMPEG2 [ISO-MPEG2]で定義されています。これは、説明します
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論理チャネルによって運ばれるコンテンツ（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多重：この文書では、この用語は、MPEG-2 TS単下位レイヤ接続を介して送信される論理チャネルのセットを定義します。これは、共通の物理リンク（すなわち、指定されたシンボルレート、FEC設定、送信周波数で送信）、または別のプロトコル層（例えば、イーサネット（登録商標）、又はIPオーバーRTP）によって提供されるカプセルであってもよいです。同じTS論理チャネルは、二つの地上波TV送信セルに同一のマルチキャストコンテンツを再配布するために、例えば複数のTS多重（おそらくは異なるPID値に関連する）[RFC4259]、上に繰り返すことができます。
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]を介して送信されるデータの固定長188Bユニット。各TSパケットは、図4（b）ヘッダを運びます。
UDL: Unidirectional link: A one-way transmission link. For example, and IP over DVB link using a broadcast satellite link.
UDL：単方向リンク：片方向伝送リンク。例えば、及びIP放送衛星リンクを使用して、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：単方向ライト級カプセル化。単一のTS論理チャネル[RFC4326]を使用してTSパケットの直列に送信されSNDUsに、PDUをカプセル化する仕組み。
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ストリーム：MPEG-2 TSのみULEは、PDUをカプセル化運ぶ論理チャネル。 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のカプセル化フォーマット、上にIPのセットをサポートするために必要とIETF定義一方向軽量カプセル化（ULE）[RFC4326]。
The general IP over MPEG-2 AR requirements are summarized below:
一般的なIP MPEG-2の上にARの要件を以下にまとめます。
- 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]).
- （[RFC3756]をマスカレードアドレスから保護するためにAR情報を認証するためのセキュリティメカニズムを含む）のIPv4 / IPv6の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情報の伝送のための方法（リンクローカルマルチキャストはブロードキャストをサブネットに好適です）。
- 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ネットワークをサポートすることができます。この場合、アドレスは、1つからパケットを防ぐために解決されるスコープは他のスコープ[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].
（ⅱ）ローカルスコープのマルチキャストアドレス。これらは、ローカルエリア内でのみ有効である（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]をスコープ。これらのアドレスの転送は、アドレスに関連付けられている範囲によって制御されています。アドレスは、アドレス指定された領域内でのみ有効である（例えば、8分の239 [RFC2365]）。
Overlapping address assignments may also occur at L2, where the same MAC/NPA address is used to identify multiple Receivers [RFC4259]:
重複アドレスの割り当ては、同じMAC / NPAアドレスが複数の受信[RFC4259]を識別するために使用されるL2、で発生することがあります。
(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.
（ⅱ）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マルチキャストアドレスのセットを表示してもよいです。対応するマルチキャスト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ネットワークは、異なるレシーバまたは別のTSを多重化を経由して同じコンテンツ（サイマルキャスト）を送信するためにIPパケットを複製することがあります。 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の手順は、特定のMAC / NPAアドレス（セクション5）でIPアドレスを関連付ける必要があります。
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
それがリンクブロードキャストのネイティブサポートの利点を利用するため、マルチキャストは、MPEG-2伝送ネットワークのための重要なアプリケーションです。マルチキャストアドレス解決はIPグループ宛先アドレス（セクション5.6）を用いて、特定のL2アドレスを関連付けることで、ネットワークレベルで発生します。このイーサネット上のIPv4とIPv6で
association is normally a direct mapping, and this is the default method also specified in both ULE [RFC4326] and MPE [ETSI-DAT].
関連付けは、通常、直接マッピングされ、これはまた、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）で生じなければなりません。このマルチキャストアドレス解決の目的は、受信機が特定のTS論理チャネルと対応するTS多重[RFC4259]でIPv4またはIPv6マルチキャストアドレスを関連付けることができるようにすることです。この関連付けは、アクティブなマルチキャストグループの多数を許可する必要があり、フィルタリング及び（例えば、TS論理チャネルの数にわたってマルチキャストトラフィックを分散させることによって）IPマルチキャストパケットを転送する場合、受信機における処理負荷を最小限に抑えるべきです。これらの不要なマルチキャストトラフィックを廃棄からドライバやオペレーティングシステムを緩和することができるので、ハードウェアフィルタリングを可能にする方式は、有益であり得ます。
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.
カプセル化機能の基本的なMPEG-2 TS論理チャネル（PID）とMPEG-2 TS多重化するために（I）のマッピングIPマルチキャストグループ。
(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（どれ・ソースマルチキャスト）アドレスの範囲内で同じIPグループの宛先アドレスを持つIPパケットを貢献するとき、これが発生する可能性があります。別の場合は、受信機が同じパケットの複数のコピーを受信することができるときに生じる（例えば、パケットが異なるTS論理チャネルあるいは異なるTS多重化し、同時放送[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
MPEG-2のネットワークがマルチキャスト対応インターネットにピアリングされたときに、IPマルチキャストグループ宛先アドレスの任意の大きな数が使用中であってもよく、伝送ネットワーク上で転送セットは、時間と共に大きく変化することが予想されてもよいです。 IPのいくつかの用途は、単一のアプリケーションをサポートするためにアドレスの範囲を使用するマルチキャスト（例えば、ND [RFC2461]、階層符号化トランスポート（LCT）[RFC3451]、および波と式ベースのレート制御（WEBRC）[RFC3738]）。アクティブなアドレスの現在のセットは、マルチキャストグループメンバーシッププロトコル（例えば、インターネットを介して動的に決定することができます
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.
マルチキャストルーティング（例えば、プロトコル独立マルチキャスト（PIM）[RFC4601]）および/または他の手段（例えば、[RFC3819]と[経由してグループ管理プロトコル（IGMP）[RFC3376]およびMulticast Listener Discovery（MLD）[RFC3810]）、 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では、MPEG2トランスポートストリーム[ISO-MPEG2は、2つのPSIテーブルの組み合わせを使用して、ストリームの存在およびフォーマットを識別する：プログラムアソシエーションテーブル（PAT）およびプログラムマップテーブルのプログラム要素ループのエントリを（PMT）。 PMTテーブルは、まれに送信され、典型的にはサイズが小さいされています。 PATは$ 000のよく知られたPID値を使用して送信されます。このテーブルは、program_numberをとPID値との対応を提供します。 （program_numberをプログラムに関連した数値ラベルです）。表内の各プログラムは、TS論理チャネル（すなわち、TS）を識別するために使用される特定のPID値、関連付けられています。識別されたTSは、プログラムの個々の成分とPID値の組を関連付けるPMTを送信するために使用されます。このアプローチは、デリファレンスPID値をMPEG-2ネットワークマルチプレクサまたはそれらが処理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.).
ストリームに割り当てられたPID値を有する受信機に信号を送ることに加えて、PMTのエントリは、マルチプレクサ、remultiplexors、レート・シェーパ、広告（MPEG-2伝送ネットワークで動作することができるデバイスの様々な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).
マルチプレクサまたはremultiplexor更新PMTに反映された新しい値、多重化プロセスの間にストリームに関連付けられたPID値を変更することができます。 TS PMTエントリ（孤立PID）に関連付けられていないPID値を運ぶパケットができ、通常の伝送ネットワークを介して転送されていないストリームで、その結果、ISO 13818-1に準拠L2機器によって廃棄されるであろう。任意の中間デバイス（例えば、シナリオ[RFC4259]のC、E、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).
IPアドレスの事前定義されたセットは、MPEG-2伝送ネットワーク内で使用されてもよいです。アドレスのアクティブセットの事前知識が適切な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 /イーサネットパケットは、MPEG-2 TSパケットにカプセル化されたケーブルモデム（単数または複数）に（下流に）送信される単一周知TS論理チャネル（PID）に送りました。インバンドシグナリングのテーブルの使用はありません。上流に、一般的なアプローチは、他の独自の方式も使用され続けているが、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）は、DOCSISケーブルモデムにIPアドレスを割り当て、DHCPサーバーを提供します。 MPEG-2伝送ネットワークは、L2は、ケーブルモデム（セクション1）にネットワーク架橋提供します。これは通常、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]によりアクセス及びSIテーブル情報の処理を必要とする、[ETSI-SI1]。この方式は、マルチメディアテレビに関連する様々なトランスポートストリームを提供し、調整の複雑さを反映しています。 TS多重化は、既存のコントロール表に追加の情報を統合することによって、または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.
DVBデータ規格（I）のIP / MAC通知テーブル（INT）[ETSI-DAT]。これは、MPEG-2 TSへのIPv4 / IPv6マルチキャストアドレスの一方向アドレス解決を提供します。
(ii) Application Information Table (AIT) in the Multimedia Home Platform (MHP) specifications [ETSI-MHP].
（ii）のアプリケーション情報テーブルマルチメディア・ホーム・プラットフォーム（MHP）仕様（AIT）[ETSI-MHP]。
(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）MPEG-2 TSにIPv4マルチキャストアドレスの一方向アドレス解決を提供するために、いくつかのDVB-RCSシステムによって使用MPEG-2テーブルです。
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).
INT [ETSI-DAT]他のMPEG-2テーブル（セクション4）と組み合わせて使用した場合、MACはIPv4、及びIPv6のARをサポートし、より一般的なDVB方式であるのに対し、MMTとAITは、特定の用途のために使用されます。
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]に指定されています。これは、IP / L2の位置に関する情報を搬送するための方法は、DVBネットワーク内を流れる提供します。 PLATFORM_IDはIP / L2ストリーム及び/又は受信機のセットのためのアドレッシング範囲を識別する。プラットフォームは、一つまたは複数の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の「サブネットマスクは」完全形またはスラッシュ記号（例えば、/ 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.
（ⅱ）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）の目標_IP_：単一またはIPv4ユニキャストまたはマルチキャストアドレス（およびそれらのマスク）のセットを記述した記述子を。
(iv) target_IP_slash_descriptor: Allows definition and announcement of an IPv4 prefix.
（ⅳ）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
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は代替の非DVB（おそらくは非IP）ネットワークを介してISPにアクセスするための第2のアドレス記述子の指定を可能にします。
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].
一つの重要な利点は、アプローチは、MPEG-2シグナル（第4章）を使用し、他のシグナリング情報と統合されていることです。これは、INTは、（再）マルチプレクサ[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機能を定義していません。しかし、アプリケーション情報テーブル（AIT）はMHP受信機が制御情報の多様を受信することを可能にするように定義されています。 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パケットの送信を可能にするシステムを規定します。 （PMTによって定義される）MPEG-2プログラムは、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プログラム要素にIPマルチキャストメディアストリームと、対応するセッション記述プロトコル（SDP）アナウンスストリームを結合するためにMPEG-2 SIテーブルを使用するように定義されています。各アプリケーションは、独立したネットワークを構成しています。 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.
その拡張の柔軟性と拡張性の面でINT、そのシンプルでMMT、およびAIT：SI / PSIに基づいて、MPEG-2の方法は、それらを作成し、それぞれが自分の強さを持っているグループの指定された要件を満たしています。しかし、彼らは、スケーラビリティの制約を発揮する技術固有のソリューションを表し、そして完全に広いインターネット内のリンク技術として、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.
TS論理チャネル（すなわち、トランスポートストリーム）にIPアドレスを解決するために、よく知られているIPマルチキャストアドレス上でIPマルチキャストプロトコルを使用することができ、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ベースのプロトコルは、TS論理チャネル（ストリームに関連付けられたPID値）にMACアドレスのマッピングおよびマッピングの両方IPの異なるネットワークシナリオに共通の方法を提供することができます。
(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プロトコルによって交換される情報を容易に、その等AAA、ポリシー、運用及び管理（OAM）、モビリティ、構成制御のサポートを簡素化し、IPネットワーク層の一部として統合することができますセキュリティと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）は多重化処理（第4）の間TS論理チャネルに関連付けられたPID値を変更MPEG-2 remultiplexors [RFC4259]を使用してMPEG-2のネットワーク上で動作することができません。これは、展開放送テレビネットワーク[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.
（ⅱ）IPベースの方法は、送信者[RFC4259]の情報および認証の整合性についての懸念を導入することができます。 （ゲートウェイ装置は、より大きなインターネットからMPEG-2のデバイスは、仮想MPEG-2プライベート作成隔離ネットワークの部分は、これらの懸念は、MPEG-2表の方法にも適用可能であるが、この場合、情報は、L2ネットワークに限定され、又はネットワーク）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レベルの方法は、よく知られている（または発見された）の上に（また、セクション5.4を参照）IPマルチキャストアドレスをAR Serverを実行しているIPマルチキャストプロトコルを使用することができます。多数のシステム（セクション1）を用いてネットワークへのスケーラビリティの要件を満たすために、単一のパケットは、複数のARレコードを搬送し、各アドレスの意図する範囲を定義する必要があります。プレフィックスマッチングを用いる方法が望ましい（例えば、送信元/宛先アドレスの範囲を単一のエントリに一致している場合）。また、IPの範囲を許可する方法を使用することが有益することができTS論理チャネルのセット（例えば、イーサネットMACアドレス[RFC1112]にIPグループ宛先アドレスのマッピングに似たハッシュ技術[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.
このセクションでは、へ/ MAC / NPAアドレスからのMPEG-2オーバーネットワークのアドレスを割り当てると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情報を必要とします。このヘッダーを完了するための情報は、隣接/ 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).
MAC / NPAアドレスにマッピングするIPアドレスの二つのIETF定義のプロトコルは、アドレス解決プロトコル、ARP [RFC826]、それぞれIPv4とIPv6の近隣探索プロトコル、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は、セキュリティの脆弱性の数を持っています。システムは、正規のネットワークシステムと不正なシステムのMACのIPアドレスを含む架空のARP応答を送信する不正なデバイスによってだまされることができる場合ARPスプーフィングです。これは、偽のマッピングで自分のARPテーブルを更新して、代わりに、合法的なシステムの不正なシステムに将来のパケットを送信するために、ネットワーク上の合法的なシステムの原因となります。この方法を使用して、不正なシステムは、ネットワークを介して送信されたパケットを参照して（および変更）することができます。
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.
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が経験するよりも著しく大きい場合。かなりの遅延（[RFC2461]のセクション6.3.2）とのネットワークリンクを使用する場合、プロトコルパラメータ（例えば、RTR_SOLICITATION_INTERVAL）のチューニングは、従って推奨されます。
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]はMAC / NPAアドレスはSNDUから省略されているモードを定義します。いくつかのシナリオでは、これは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):
三つの異なる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).
(ii) A Receiver needs the Feed Router MAC/NPA address.
（ⅱ）Aレシーバは、フィードルータ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.
(iii) A Receiver needs another Receiver MAC/NPA address.
（III）A Receiverは他の受信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.
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、及びSENDによって提供される反応アドレス解決手順の性能。イーサネットとは対照的に、解像度が行われている期間中に、多くのIPパケットは、ARのターゲットアドレスにアドレス指定されている受信することができます。 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）において、アドレス解決が完了するまでの時間は、フィード（5.4）におけるARサーバーを使用することによって低減することができます。
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ネットワークであることができる二MPEG-2伝送リンクの組み合わせによって構成されています。一つのリンクは、通常、遠隔受信機のセットを供給し、ブロードキャストリンクです。リンクはまた、受信機から提供されるように、全二重インタフェースとして合成リンク機能。この使用の例は、双方向の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サーバーは、MPEG-2のネットワーク内の受信機にAR情報を配信するために使用することができます。一部のトポロジでは、これは大幅に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 Serverは、受け取ったAR要求にレシーバに代わって代理応答として動作することができます。 IPv4のAR要求を受信した場合（例えば、受信ARP REQUEST）は、ARサーバ（プロキシ）、AR応答を送信する（L2アドレスにIPアドレスをマッピング）結合MAC / NPAに適切な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).
レシーバからのAR要求が傍受ではなく、フィード/ブロードキャストリンクに転送されるように、AR Serverは、サブネットワークを構成することにより、IETF定義のプロトコルを用いて実現することができます。インターセプトされたメッセージは、AR Serverに送信されます。 AR Serverは、MAC / NPAアドレスバインディングのセットを保持しています。これらは、構成することができるか、レシーバにより送信されたARPメッセージを監視することで学んだことがあります。現在定義されているIETFプロトコルは一つだけ（すなわち、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プロキシは、中間ボックス装置内のシステムの状態を記憶します。これは古典的なman-in-the-middleセキュリティ攻撃に似ています。 SENDとの相互作用は、[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モビリティ、ネットワークトポロジの変更、または断続的なレシーバの接続）。これらの場合、古い（失効）情報の使用は、結果として、パケット損失、不適切L2アドレスに向けられたIPパケットをもたらすことができます。
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アドレスのバインディングを提供するが、この機能（セクション4）のための他の方法の使用を必要とする、適切なMPEG-2ネットワークへの他のL2情報にバインディングを許可しません。 ARサーバーもレシーバで必要とされるAR情報を提供するために、非IETF 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は、2つの成分からなる：DHCPクライアントにDHCPサーバからシステム固有の構成パラメータを配信するためのプロトコル（例えば、デフォルトルータ、DNSサーバ）とシステムへのネットワーク・アドレスの割り当てのためのメカニズム。
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メッセージを再送信することができます。いくつかのクライアントの実装は、DHCPサーバーが上のチェックの満了前にDHCPDISCOVER再送に応答するのに十分な時間を提供する（イーサネット遅延ではなく、MPEG-2のネットワークへの適切なに適し、例えば）小さい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のIPマルチキャストアドレス[RFC1112]とIPv6 [RFC2464]に基づいて、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.
これらの考慮事項は、イーサネットLANの場合と同じで、かつ効率的なL3フィルタリングを実行することができる受信機への懸念ではないかもしれません。セクション3は、MPEG-2のネットワークは、ネットワークおよびリンク層に複数のアドレッシング範囲をサポートする必要があることに留意しました。異なるトランスポートストリームに異なるグループの分離は（PID値へのマッピングIPのシグナリングを持つ）1つの救済策です。別のアプローチは、[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ツリーチェックをまたがる、IP時間の処理（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アドレスを破棄するフィルタを使用してリンク層で濾過してもよいです。いくつかの状況では、システムは、L2のソースは、受信機で決定することができない（全てゼロ）未知のMACソースアドレス（例えば、IGMPプロキシクエリア[RFC4605]）を用いてパケットを送信することができます。これらのパケットは、レシーバに関連したサービスを実行妨げる可能性がある、静かに捨てられる必要があります。
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（ブートストラッププロトコル）[RFC951]、DHCP [RFC2131]及びND [RFC2461]）L3にソースが受信機で決定することができない、これらのパケットが必要とするパケットを送信することができ黙って破棄されます。これが受信機に関連したサービスを実行できない場合があり、例えば、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法をサポートするのに必要な送信のカプセル化の効率：これは二つの問題を検討します。以下の表は、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ネットワークをサポートするために、唯一の方法（例えば、ULE又はMPE）を使用しなければならない（すなわち、同一のサブネット・ブロードキャスト・アドレスまたは同一のIPv6プレフィックスを共有するのIPv4システムのセット）。 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受信機は両方の方法を実装するために必要とされる）に対処するために通常モードと組み合わせて使用することができます。受信機のMACアドレスに対応する宛先アドレスを有し、レシーバインターフェイスに対応するIPアドレスを持つULEブリッジモードを使用して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)
表1：L2サポートおよびオーバーヘッド（X =サポートされている、 - =サポートされていません）
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、ARPおよびNDプロトコルにはMAC / NPAアドレスが存在しないため、ARには必要ありません。
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ネットワークアドレスを設定することができます。自動構成を使用するように、受信機でIPドライバは、この値が受信SNDUsをフィルタリングするために使用されていない場合であっても、受信インタフェースの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）システムが有していてもよいものから、本来自身が送信され、再放送であったDADパケットを区別することができないあります同じL3アドレスと他のシステムによって送信され。したがって、DADは、この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]上で使用することができます。何MAC送信元アドレスは、ULE SNDUに存在しないが、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）システムが有していてもよいものから、本来自身が送信され、再放送であったDADパケットを区別することができないあります同じL3アドレスと他のシステムによって送信され。したがって、DADは、この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]をサポートしてもよいです。これが実行される方法を定義する規定はありません。プロトコルは、それが生成する任意のクエリメッセージのARPレコードペイロード内の送信元MACアドレスを通信がありませんMAC送信元アドレスは、SNDUに存在しています。
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）システムが有していてもよいものから、本来自身が送信され、再放送であったDADパケットを区別することができないあります同じL3アドレスと他のシステムによって送信され。したがって、DADは、この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宛先アドレスはNPA宛先アドレスに使用されるものとしてULE SNDUにおける同じ位置を有します。 MAC宛先アドレス値がReceiver 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転送決定によって決定されます。受信フレームは転送されてもよいまたはReceiver自身に対処することができます。他L2のLANのように、受信器は、設定されたMAC宛先アドレスフィルタに基づいて、受信したフレームをフィルタリングすることを選択することができます。 ARPとNDメッセージは、このカプセル化形式によって架橋されたPDUの中で運ばれてもよいです。トポロジは本来レシーバ（例えば、セクション5.6.1）によって送信されたマルチキャストフレームの再放送のコピーのその後の受信をもたらすことができる場合、システムは、それが送信されたフレームに使用される送信元アドレスで受信されたフレームを廃棄しなければなりません同じインターフェイス[802.1D]から。これは、（例えば、これはそうでなければDADを呼び出すことになる）ブリッジネットワーク上の複製を防止します。
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]から送信されたフレーム。これは、（例えば、これはそうでなければDADを呼び出すことになる）ブリッジネットワーク上の複製を防止します。
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アドレスの両方を供給する。フォーマットは、2つのMAC宛先アドレスを定義MPE SNDU（すなわち、レシーバMACアドレス）とブリッジMACフレームと一つと関連する一つ（すなわち、リモートLANに意図された受信者の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）によって送信されたマルチキャストフレームの再放送のコピーのその後の受信をもたらすことができる場合、システムはそれに使用されるソースアドレスで受信されたフレームを廃棄しなければなりません同じインターフェイス[802.1D]から送信されたフレーム。これは、（例えば、これはそうでなければDADを呼び出すことになる）ブリッジネットワーク上の複製を防止します。
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のために構成されてもよいです。ブロードキャストネットワークでは、この情報は、通常エンカプスレータ/マルチプレクサによって提供され、シグナリングテーブルで運ばれる（例えば、AIT DVBのMHP、IP通知表、INT、およびDVB-RCSマルチキャストマッピングテーブル、およびMMT）です。この文書では、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の場合、SENDプロトコル[RFC3971]はNDの代わりに使用することができます。これは、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の送信を受け付けます。これらのメソッドを使用する場合には、ARPおよびNDのセキュリティはプライベートLANに匹敵することができ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 Serverは、本質的に正当なman-in-the-middle、不要なman-in-the-middle攻撃から、このようなプロキシを区別する必要があることを意味しています。この文書では、（例えば、サーバを認証する、またはSENDプロトコル[SP-ND]と相互運用ARサーバーを定義する）これらのAR機能の保護のための新しいメカニズムを導入しません。
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).
作者は彼らの入力と、特に、ロッド・ウォルシュ、6月武井、そしてマイケルMercurioのためIPDVB WGメンバーに感謝したいです。著者らはまた、欧州宇宙機関の支援を認めます。マーティンStiemerlingは、シナリオの記述を貢献した構成、および豊富な証拠の読みを提供します。秀隆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：システム" IS、国際標準化機構（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]プラマー、D.、：、STD 37、RFC 826、1982年11月「イーサネットアドレス解決プロトコルやネットワーク・プロトコルを変換するには、イーサネットハードウェア上での伝送のためのイーサネットアドレスを48ビットにIPアドレス」。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、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.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]クロフォード、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.、藤井、N.、およびY.チャン、 "単方向リンクのリンク層トンネル機構"、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.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、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]、RFC 4326 "MPEG-2トランスポートストリーム（TS）上のIPデータグラムの送信の一方向軽量カプセル化（ULE）" Fairhurst、G.およびB. Collini-Nocker、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デジタルテレビジョン規格"、高度テレビジョンシステム委員会（ATSC）、ドク。 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）、ドク "ATSCデジタルテレビ規格の使用ガイド"。 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データ放送規格"、高度テレビジョンシステム委員会（ATSC）、ドク。 / 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）、ドク "ATSCデータ放送上のIPマルチキャストセッションの配達"。 / 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の、文書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).
301 421 EN [ETSI-DVBS]、 "デジタルビデオ放送（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.クルックシャンク、S.アイアンガー、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は、IS「情報技術 - 映画と関連オーディオ情報のジェネリックコーディング - パート6：DSMCCのための拡張機能は、完全なソフトウェア実装である」、国際標準化機構（ISO） 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フォーラム、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]クロフト、W.及びJ.ギルモア、 "ブートストラッププロトコル"、RFC 951、1985年9月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365]マイヤー、D.、 "管理スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[RFC2375] HindenとR.とS.デアリング、 "IPv6のマルチキャストアドレスの割り当て"、RFC 2375、1998年7月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]パトリック、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. Woundy、「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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]バラクリシュナン、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]ルビー、M.、Gemmell、J.、Vicisano、L.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト、 "階層化符号化トランスポート（LCT）ビルディングブロック"、RFC 3451、2002年12月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]バッタチャリヤ、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.、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate Control (WEBRC) Building Block", RFC 3738, April 2004.
[RFC3738]ルビー、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.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、RFC 3810、2004年6月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]カーン、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、「アドバイスインターネットサブネットワークデザイナー」、BCP 89、RFC 3819、2004年7月のため。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（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]ヴァイス、B.、RFC 4359、2006年1月 "カプセル化セキュリティペイロード（ESP）と認証ヘッダー（AH）内のRSA / SHA-1署名の使用"。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]ターラー、D.、Talwar、M.、およびC.パテル、 "近隣探索プロキシ（NDプロキシ）"、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]フェナー、B.、ハンドリー、M.、ホルブルック、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]フェナー、B.、彼、H.、ハーバーマン、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.、アハメド、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.、デイヴィス、E.、およびD.ターラー、 "有害と考えられ、複数のカプセル化メソッド"、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]デイリー、G.、 "確保プロキシ近隣探索問題文"、進歩、2005年2月に作業。
Authors' Addresses
著者のアドレス
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK
アバディーン、AB24 3UE英国のエンジニアリング大学のGodred Fairhurst部門
EMail: gorry@erg.abdn.ac.uk URL: http://www.erg.abdn.ac.uk/users/gorry
メールアドレス：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
マリー・ジョゼMontpetitモトローラは、ホームソリューションアドバンスト・テクノロジー55ヘイデン・アベニュー、3階レキシントン、マサチューセッツ02421 USAを接続しました
EMail: mmontpetit@motorola.com
メールアドレス：mmontpetit@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。