RFC4947 日本語訳
4947 Address Resolution Mechanisms for IP Datagrams over MPEG-2Networks. G. Fairhurst, M. Montpetit. July 2007. (Format: TXT=102717 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Fairhurst
Request for Comments: 4947 University of Aberdeen
Category: Informational M.-J. Montpetit
Motorola Connected Home Solutions
July 2007
Fairhurstがコメントのために要求するワーキンググループG.をネットワークでつないでください: 4947年のアバディーン大学カテゴリ: 情報のM.J。 Montpetitモトローラコネクテッドホームソリューション2007年7月
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).
IETFが信じる著作権(C)(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.
このドキュメントはMPEG-2Transport Streams(TS)と共に結合/仲間IPv4/IPv6アドレスのプロセスについて説明します。 この手順はAddress Resolution(AR)かNeighborディスカバリー(ノースダコタ)として知られています。 そのようなアドレス解決は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-2Networksでは、IPアドレスはPacket ID(PID)値と特定のTransmission Multiplexに関連しているに違いありません。 このドキュメントはさまざまな技術(DVB(デジタルVideo Broadcasting)や、ATSC(高度なTelevision Systems Committee)や、DOCSIS(データ過剰Cable Service Interface Specifications)や、異形などの)に適切な現在のメソッドを見直します。 また、それはアドレス管理のためのDHCP、ARP、およびノースダコタプロトコルを含んでいるよく知られるプロトコルとの相互作用について説明します。
Fairhurst & Montpetit Informational [Page 1] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[1ページ]のRFC4947ARメカニズム
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
1. 序論…3 1.1. ブリッジするのとルート設定…4 2. このドキュメントで中古のコンベンション…7 3. 解決要件を扱ってください…10 3.1. ユニキャストサポート…12 3.2. マルチキャストサポート…12 4. MPEG-2は解決を扱います…14 4.1. 静的な構成…15 4.1.1. MPEG-2つのケーブルネットワーク…15 4.2. MPEG-2のテーブルベースのアドレス解決…16 4.2.1. IP/MAC通知テーブル(INT)とその用法…17 4.2.2. マルチキャストマッピングテーブル(MMT)とその用法…18 4.2.3. アプリケーション情報テーブル(オート麦)とその用法。18 4.2.4. ATSCで解決を扱ってください…19 4.2.5. SI/ψテーブルの比較にアプローチします…19 4.3. t論理チャネルのためのIPベースのアドレス解決…19 5. IPを写像すると、アドレスはMAC/NPAに扱われます…21 5.1. 単方向が接続性であるとサポートしながら、単方向はリンクされます…22 5.2. 単方向は双方向の接続性にリンクされます…23 5.3. 双方向のリンク…25 5.4. ARサーバ…26 5.5. DHCPチューニング…27 5.6. IPマルチキャストAR…27 5.6.1. UDLRのためのマルチキャスト/放送アドレシング…28 6. 層のサポートをリンクしてください…29 6.1. 目的地MAC/NPAのないULEは(D=1)を扱います…30 6.2. 目的地MAC/NPAとULEは(D=0)を扱います…31 6.3. LLC/スナップカプセル化のないMPE…31 6.4. LLC/スナップカプセル化があるMPE…31 6.5. ヘッダー拡大(D=1)をブリッジするULE…32 6.6. ヘッダー拡大とNPAをブリッジするULEは(D=0)を扱います。32 6.7. LLC/スナップとブリッジするのがあるMPE…33 7. 結論…33 8. セキュリティ問題…34 9. 承認…35 10. 参照…35 10.1. 標準の参照…35 10.2. 有益な参照…36
Fairhurst & Montpetit Informational [Page 2] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[2ページ]のRFC4947ARメカニズム
1. Introduction
1. 序論
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.
このドキュメントはMPEG-2Transport Streams(TS)と共に結合/仲間IPv4/IPv6アドレスのプロセスについて説明します。 この手順はAddress Resolution(AR)、またはNeighborディスカバリー(ノースダコタ)として知られています。 そのようなアドレス解決はIPセッションの広告を出すのに使用されるより高い層のリソース発見ツールの補足となります。 ドキュメントはさまざまな技術(DVB、ATSC、DOCSIS、および異形)に適切な現在のメソッドを見直します。 また、それはアドレス管理のためのDHCP、ARP、およびノースダコタプロトコルを含んでいるよく知られているプロトコルとの相互作用について説明します。
The MPEG-2 TS provides a time-division multiplexed (TDM) stream that may contain audio, video, and data information, including encapsulated IP Datagrams [RFC4259], defined in specification ISO/IEC 138181 [ISO-MPEG2]. Each Layer 2 (L2) frame, known as a TS Packet, contains a 4 byte header and a 184 byte payload. Each TS Packet is associated with a single TS Logical Channel, identified by a 13-bit Packet ID (PID) value that is carried in the MPEG-2 TS Packet header.
MPEG-2TSがオーディオを含むかもしれない時間分割の多重送信された(TDM)ストリームを提供します、ビデオ、そして、カプセル化されたIPデータグラム[RFC4259]を含むデータ情報が仕様に基づきISO/IEC138181[ISO-MPEG2]を定義しました。 TS Packetとして知られているそれぞれのLayer2(L2)フレームは4バイトのヘッダーと184バイトのペイロードを含んでいます。 それぞれのTS Packetは独身のTS Logical Channel(MPEG-2TS Packetヘッダーで運ばれる13ビットのPacket 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規格はSystem情報(SI)テーブル[ETSI-SI]、[ETSI-SI1]、またはProgram Specific情報(PSI)テーブルの形で制御情報をReceiversに伝えるのに使用されるかもしれない制御飛行機を定義します。
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-2TSを利用するために、送付者は特定のTransmission Multiplexと、マルチプレックスの中でIPアドレスを関連づけなければなりません、と使用されるべき特定のPIDは特定します。 このドキュメントは、このマッピングをAR機能と呼びます。 いくつかのAR体系では、MPEG-2TSアドレス空間はPlatforms[ETSI-DAT]として知られている論理的な関係に細分されます。 各Platformは一般的なMPEG-2TS(すなわち、同じPID値を使用する)を共有する別々の関係に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-2Receiversが、MPEG-2送電網の中で唯一L2ノードを特定するのにAttachment(NPA)[RFC4259]のNetwork Pointを使用するかもしれません。 NPAに関する例はIEEE Medium Access Control(MAC)アドレスです。 また、そのようなアドレスが使用されているところでは、AR手順でこれらに合図しなければなりません。 最終的に、アドレス決議は例えば送られるデータの形式を示すかもしれません、カプセル化、どんなL2暗号化メソッドとどんな圧縮技術[RFC4259]でも。
The numbers of Receivers connected via a single MPEG-2 link may be much larger than found in other common LAN technologies (e.g., Ethernet). This has implications on design/configuration of the address resolution mechanisms. Current routing protocols and some multicast application protocols also do not scale to arbitrarily
単一のMPEG-2リンクを通して接続されたReceiversの数は他の一般的なLAN技術(例えば、イーサネット)で見つけられるよりはるかに大きいかもしれません。 これはまた. 現在のルーティング・プロトコルといくつかのマルチキャストアプリケーション・プロトコルが任意に比例しないアドレス解決メカニズムのデザイン/構成に意味を持っています。
Fairhurst & Montpetit Informational [Page 3] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[3ページ]のRFC4947ARメカニズム
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に建てられます。 このより高い遅れは、このサービスを利用するアドレス解決プロトコルによって設備される必要があるかもしれません。
1.1. Bridging and Routing
1.1. ブリッジするのとルート設定
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の発送されたaとブリッジしているサブネットワークの使用を例証します。 また、L2とL3推進の他の様々な組み合わせはMPEG-2個のリンクの上に使用されるかもしれません(IP終わりのホストと終わりのホストであるReceiversを含んでいるのは直接ブリッジしているLANセグメントに接続しました)。
Broadcast Link AR
- - - - - - - - -
| |
\/
1a 2b 2a
+--------+ +--------+
----+ R1 +----------+---+ R2 +----
+--------+ MPEG-2 | +--------+
Link |
| +--------+
+---+ R3 +----
| +--------+
|
| +--------+
+---+ R4 +----
| +--------+
|
|
リンクARを放送してください--、--、--、--、--、--、--、--、-| | \/1a 2b 2a+--------+ +--------+ ----+ R1+----------+---+ R2+---- +--------+ MPEG-2| +--------+ リンク| | +--------+ +---+ 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は、発送されたMPEG-2リンクが3つの川下のルータ(R2-R4)を食べさせるのを示します。 ARは、IPサブネットワーク(R2など)の中でLayer2の各Receiverを特定するためにEncapsulator(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(発信)インターフェース・アドレスです。
Fairhurst & Montpetit Informational [Page 4] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[4ページ]のRFC4947ARメカニズム
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に次のホップReceiverに対応するL2アドレス(2b)を決定させます、ルータR2。
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は、ブリッジしているMPEG-2リンクが3つの川下のブリッジ(B2-B4)を食べさせるのを示します。 ARは、L2(B2-B4)の各Receiverを特定するためにEncapsulator(B1)で行われます。 また、Feedルータ(R1)がLayer2(R2など)で川下のRoutersを特定するのを許容しながら、ARはIPサブネットワークの向こう側に行われます。 それぞれがPDUであるとブリッジされている送付先MAC/NPAアドレスがMPEG-2で送ったEncapsulator関連はリンクします。 2つのメソッドがULE(単方向ライト級Encapsulation)[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アドレスです。 これは、各Receiver(B2-B4)がそれが与えるL2サブネットワークの上に存在するMACアドレスのセットとの受信MPEG-2インタフェースを関連づけるのを必要とします。 IPベースのトンネルがサービス(UDLR(Unidirectionalリンクス)[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.
また、ブリッジするEncapsulator(B1)がまた、MPEG-2リンク(図2)の上のReceiver L2インタフェースに関連しているMAC/NPAアドレスを含むリンク特有のヘッダーと共にPDUをカプセル化するのも、可能です。 この場合、カプセル化されたフレームの送付先MAC/NPAアドレスは最終的なL2の目的地のアドレスよりむしろReceiver MAC/NPAアドレス(y)に設定されます。 また、異なったレベルでは、R1が送付先L2アドレス2bをR2に関連づけるのにAR結合が必要です。 ブリッジすることを使用するサブネットワークでは、通常、システムのR1とR2はIPサブネットワークの向こう側に標準のIETFによって定義されたARメカニズム(例えば、IPv4 Address Resolutionプロトコル(ARP)[RFC826]とIPv6 Neighborディスカバリープロトコル(ノースダコタ)[RFC2461])の縁から縁を使用するでしょう。
Fairhurst & Montpetit Informational [Page 5] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[5ページ]のRFC4947ARメカニズム
Subnetwork AR
- - - - - - - - - - - - - - - -
| |
サブネットワークAR--、--、--、--、--、--、--、--、--、--、--、--、--、--、--、-| |
| MPEG-2 Link AR |
- - - - - - - - -
| | | |
\/ \/
1a x y 2b 2a
+--------+ +----+ +----+ +--------+
----+ R1 +--| B1 +----------+---+ B2 +--+ R2 +----
+--------+ +----+ MPEG-2 | +----+ +--------+
Link |
| +----+
+---+ B3 +--
| +----+
|
| +----+
+---+ B4 +--
| +----+
|
| MPEG-2リンクAR| - - - - - - - - - | | | | \/\/1a x y2b 2a+--------+ +----+ +----+ +--------+ ----+ R1+--| B1+----------+---+ B2+--+ R2+---- +--------+ +----+ MPEG-2| +----+ +--------+ リンク| | +----+ +---+ 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]).
また、メソッドは、ネットワーク(例えば、状態がない自動構成[RFC2461]、DHCP[RFC2131]、DHCPv6[RFC3315]、および状態がないDHCPv6[RFC3736])の中でIPアドレスをReceiversに割り当てるために存在しています。 また、受信機は接続設備(例えば、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 Multiplex、PID値、MAC/NPAアドレス、そして/または、Platform IDにIPアドレスを関連づけるために現在のメカニズムと彼らの使用について説明します。 さまざまなアプローチが説明されます、IPレベルでLayer2メカニズム(MPEG-2個のSIテーブルを使用する)、およびプロトコルを含んでいて(ARP[RFC826]とノースダコタ[RFC2461]を含んでいて)。 これらのメカニズムとカプセル化メソッドの間の相互作用と依存は説明されます。 ドキュメントは、新しいプロトコルを提案もしませんし、定義もしませんが、IPベースのアドレス解決を供給すると考えられる必要がある問題で指導を提供します。
Fairhurst & Montpetit Informational [Page 6] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[6ページ]のRFC4947ARメカニズム
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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.
オート麦: MultimediaホームPlatform(MHP)仕様[ETSI-MHP]でアプリケーション情報Tableは指定しました。 このテーブルはMPEG-2TSアドレス解決情報まで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 MPEG-2規格[ISO-MPEG2]を使用するビデオ、オーディオ、およびデータの伝達のための1セットの関連規格。
b: bit. For example, one byte consists of 8-bits.
b: ビット。 例えば、1バイトは8ビットから成ります。
B: Byte. Groups of bytes are represented in Internet byte order.
B: バイト。 バイトのグループはインターネットバイトオーダーで代表されます。
DSM-CC: Digital Storage Media Command and Control [ISO-DSMCC]. A format for the transmission of data and control information carried in an MPEG-2 Private Section, defined by the ISO MPEG-2 standard.
DSM-CC: デジタル蓄積メディアは、[ISO-DSMCC]を命令して、制御します。 データと制御情報の伝達のための形式はISO MPEG-2規格によって定義されたMPEG-2兵士のセクションで運ばれました。
DVB: Digital Video Broadcasting [DVB]. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data, using the ISO MPEG-2 Standard.
DVB: [DVB]を放送するデジタルビデオ。 ヨーロッパのTelecommunications Standards Institute(ETSI)によって関連規格のフレームワークとセットはビデオ、オーディオ、およびデータの伝達のために発行されました、ISO MPEG-2Standardを使用して。
DVB-RCS: Digital Video Broadcast Return Channel via Satellite. A bidirectional IPv4/IPv6 service employing low-cost Receivers [ETSI-RCS].
DVB-RCS: Satelliteを通したデジタルVideo Broadcast Return Channel。 安価のReceivers[ETSI-RCS]を使う双方向のIPv4/IPv6サービス。
DVB-S: Digital Video Broadcast for Satellite [ETSI-DVBS].
DVB-S: デジタルビデオは衛星[ETSI-DVBS]のために放送されました。
Encapsulator: A network device that receives PDUs and formats these into Payload Units (known here as SNDUs) for output as a stream of TS Packets.
Encapsulator: 出力のためにTS Packetsの流れとして有効搭載量Units(ここで、SNDUsとして知られている)にPDUsを受けて、これらをフォーマットするネットワークデバイス。
Feed Router: The router delivering the IP service over a Unidirectional Link.
ルータを食べさせてください: IPサービスオーバーにUnidirectional Linkを提供するルータ。
INT: Internet/MAC Notification Table. A unidirectional address resolution mechanism using SI and/or PSI Tables.
INT: インターネット/MAC通知テーブル。 SI、そして/または、PSI Tablesを使用する単方向のアドレス解決メカニズム。
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]。 IEEE802.3規格(またはイーサネットv2)によって定義されたリンクレイヤプロトコル。
MAC Address: A 6-byte link layer address of the format described by the Ethernet IEEE 802 standard (see also NPA).
マックーアドレス: イーサネットIEEE802規格(また、NPAを見る)によって説明された形式の6バイトのリンクレイヤアドレス。
Fairhurst & Montpetit Informational [Page 7] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[7ページ]のRFC4947ARメカニズム
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ヘッダー: IEEE802.3規格[IEEE-802.3]かイーサネットv2のリンクレイヤヘッダー。 それは6バイトの送付先アドレス、6バイトのソースアドレス、およびタイプがさばく2バイトから成ります(また、NPAを見てください、LLC(論理的なLink Control))。
MHP: Multimedia Home Platform. An integrated MPEG-2 multimedia Receiver, that may (in some cases) support IPv4/IPv6 services [ETSI-MHP].
MHP: マルチメディアホームプラットホーム。 (いくつかの場合、)統合MPEG-2マルチメディアReceiverであり、それは、IPv4/IPv6サービスが[ETSI-MHP]であるとサポートするかもしれません。
MMT: Multicast Mapping Table (proprietary extension to DVB-RCS [ETSI-RCS] defining an AR table that maps IPv4 multicast addresses to PID values).
MMT: マルチキャストMapping Table(IPv4マルチキャストアドレスをPID値に写像するARテーブルを定義するDVB-RCS[ETSI-RCS]への独占拡大)。
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: Multiprotocolカプセル化[ETSI-DAT]、[ATSC-A90。] DSM-CC Tableセクションを形成して、PDUsをカプセル化するメソッド。 一連のTS Packetsで独身のStream(TS Logical Channel)を使用することで各セクションを送ります。
MPEG-2: A set of standards specified by the Motion Picture Experts Group (MPEG), and standardized by the International Standards Organization (ISO/IEC 113818-1) [ISO-MPEG2], and ITU-T (in H.220).
MPEG-2: エムペグ(MPEG)によって指定されて、国際Standards Organization(ISO/IEC113818-1)[ISO-MPEG2]、およびITU-T(H.220の)によって標準化された1セットの規格。
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: 接着点をネットワークでつないでください。 Receivers[RFC4259]の個々のReceiversかグループを特定するのに使用される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.
パット: 協会テーブルをプログラムしてください。 MPEG-2PSI制御卓。 それは関連PMT(プログラムMap Table)を送るのに使用されるPID値に各プログラムを関連づけます。 テーブルが、0×000のよく知られるPID値が使用させられて、MPEG-2対応することのTransport Streamに必要です。
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 Packetのヘッダーで運ばれました。 これはTS Packetが属するTS Logical Channel[ISO-MPEG2]を特定します。 Tableセクションの部分を形成するTS Packets、何らかの、有効搭載量Unitは同じPID値をすべて運ばなければなりません。 すべてのもののPID値はTS Multiplexの固定ビットレートを維持するために導入されたNull TS Packetを示します。 異なったTS Multiplexesを使用することで伝えられたTS Logical Channelsに使用されるPID値の間のどんな必要な関係もありません。
Fairhurst & Montpetit Informational [Page 8] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[8ページ]のRFC4947ARメカニズム
PMT: Program Map Table. An MPEG-2 PSI control table that associates the PID values used by the set of TS Logical Channels/ Streams that comprise a program [ISO-MPEG2]. The PID value used to send the PMT for a specific program is defined by an entry in the PAT.
PMT: 地図テーブルをプログラムしてください。 プログラム[ISO-MPEG2]を包括するTS Logical Channels/ストリームのセットによって使用されたPID値を関連づけるMPEG-2PSI制御卓。 具体的計画のために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]のTable2-30によると、構成された統語構造。 構造は、1つ以上の基本のストリーム、特定のMPEG-2プログラム、または全体のTransport Streamに関連しながら個人情報(すなわち、[ISO-MPEG2]が定義されない)を特定するのに使用されるかもしれません。 他のStandardsボディー(例えば、ETSIとATSC)は、個人的な_セクション構造を使用することでテーブル構造のセットを定義しました。 兵士のセクションは、TS Packetsの系列としてTS Logical Channelを使用することで伝えられます。 TS Logical Channelは1セット以上のテーブルからセクションを運ぶかもしれません。
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 Multiplexで提供されたサービスに関して情報を伝達するのに使用されます。 SI Tableも、それが4個の明確に特定されたTableセクション構造物[ISO-MPEG2]の1つで運ばれるのを見ます。
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 Multiplexから信号を処理して、フィルタリングと推進を実行する設備はネットワーク層サービスにPDUsをカプセル化しました(リンクレイヤで作動するとき、モジュールをブリッジして)。
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 Multiplexで提供されたサービスに関して情報を伝達します。 Tableは1つ以上のTableセクションから成るかもしれなくて、しかしながら、独身のTS Logical Channel[ISO-MPEG2]の上まで特定のSI Tableのすべてのセクションを運ばなければなりません。
SNDU: Subnetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit.
SNDU: サブネットワークデータ単位。 カプセル化されたPDUはMPEG-2有効搭載量Unitとして発信しました。
Table Section: A Payload Unit carrying all or a part of an SI or PSI Table [ISO-MPEG2].
セクションをテーブルの上に置いてください: すべてを運ぶ有効搭載量UnitかSIかPSI Table[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.
t: MPEG-2レベルにおけるトランスミッションのメソッドがTS Packetsを使用して、Stream[ISO-MPEG2]を輸送してください。 それはISO/OSI参照モデルのLayer2を表します。 また、TS Logical ChannelとTS Multiplexを見てください。
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
t論理チャネル: ストリーム論理チャネルを輸送してください。 本書では、今期はMPEG-2レベル[ISO-MPEG2]でチャンネルを特定します。 これはISO/OSI参照モデルのレベル2で存在しています。 TS Logical Channelの上に送られたすべてのパケットが同じPID値を運びます(この値は特定のTS Multiplexの中でユニークです)。 「ストリーム」という用語はMPEG-2[ISO-MPEG2]で定義されます。 これは説明します。
Fairhurst & Montpetit Informational [Page 9] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[9ページ]のRFC4947ARメカニズム
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 Logical Channelによって運ばれました(ULE Streamを見てください)。 いくつかのPID値が特定のシグナリングのために予約されます(MPEG-2つ)。 また、他の規格(例えば、ATSCとDVB)は特定のPID値を予約します。
TS Multiplex: In this document, this term defines a set of MPEG-2 TS Logical Channels sent over a single lower layer connection. This may be a common physical link (i.e., a transmission at a specified symbol rate, FEC setting, and transmission frequency) or an encapsulation provided by another protocol layer (e.g., Ethernet, or RTP over IP). The same TS Logical Channel may be repeated over more than one TS Multiplex (possibly associated with a different PID value) [RFC4259], for example, to redistribute the same multicast content to two terrestrial TV transmission cells.
tは多重送信されます: 本書では、今期は単独の下層接続の上に送られたMPEG-2TS Logical Channelsの1セットを定義します。 これは、一般的な物理的なリンク(すなわち、指定されたシンボルレート、FEC設定、および伝染率でのトランスミッション)か別のプロトコル層で提供されたカプセル化であるかもしれません(例えば、イーサネット、またはIPの上のRTP)。 例えば、同じTS Logical Channelは、2つの地球のテレビのトランスミッションセルに同じマルチキャスト内容を再配付するために1TS Multiplex(ことによると異なった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.
tパケット: データの固定長188B単位はTS Multiplex[ISO-MPEG2]を移動しました。 各TS Packetは4Bヘッダーを運びます。
UDL: Unidirectional link: A one-way transmission link. For example, and IP over DVB link using a broadcast satellite link.
UDL: 単方向のリンク: 一方向トランスミッションリンク。 例えば、そして、放送衛星中継を使用するDVBリンクの上のIP。
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].
ウレ: 単方向のライト級カプセル化。 一連のTS Packetsで独身のTS Logical Channel[RFC4326]を使用することで送られるSNDUsにPDUsをカプセル化する体系。
ULE Stream: An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [RFC4326, ISO-MPEG2].
ULEは流れます: ULEだけを運ぶMPEG-2TS Logical ChannelはPDUsをカプセル化しました。 ULE Streamsは定義上SI/PSI[RFC4326、ISO-MPEG2]のストリーム_タイプに特定されるかもしれません。
3. Address Resolution Requirements
3. アドレス解決要件
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アドレス解決プロセスは、カプセル化の選択から独立していて、MPEG-2つのカプセル化形式でIPの1セットを支える必要があります、Multi-プロトコルEncapsulation(MPE)[ETSI-DAT]、[ATSC-A90)、およびIETFによって定義されたUnidirectionalライト級Encapsulation(ULE)[RFC4326]を含んでいて。
The general IP over MPEG-2 AR requirements are summarized below:
MPEG-2の上の一般的なIP AR要件は以下へまとめられます:
- A scalable architecture that may support large numbers of
systems within the MPEG-2 Network [RFC4259].
- MPEG-2Network[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 Serverを特定するメソッド(例えば、よく知られるL2/L3アドレス/アドレス)。
Fairhurst & Montpetit Informational [Page 10] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[10ページ]のRFC4947ARメカニズム
- A method to represent IPv4/IPv6 AR information (including
security mechanisms to authenticate the AR information to
protect against address masquerading [RFC3756]).
- IPv4/IPv6 AR情報(アドレス仮装[RFC3756]から守るためにAR情報を認証するためにセキュリティー対策を含んでいる)を表すメソッド。
- A method to install AR information associated with clients at
the AR Server (registration).
- AR Server(登録)のクライアントに関連している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 Serverからトランスミッション費用(リンク地方のマルチキャストはサブネット放送より望ましい)を最小にするクライアントまでの伝達のためのメソッド。
- 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].
(ii)ローカルの範囲マルチキャストアドレス。 これらは局部の中で有効であるだけです。(IPv4のための例は224.0に.0/24;224.0にである:.1 /24)。 類例はいくつかのIPv6マルチキャストアドレス[RFC2375]のために存在しています。
(iii) Scoped multicast addresses [RFC2365] and [RFC2375].
Forwarding of these addresses is controlled by the scope
associated with the address. The addresses are only valid
within an addressed area (e.g., the 239/8 [RFC2365]).
(iii)はマルチキャストアドレス[RFC2365]と[RFC2375]を見ました。 これらのアドレスの推進はアドレスに関連している範囲によって制御されます。 アドレスは扱われた領域(例えば、239/8[RFC2365])の中で有効であるだけです。
Overlapping address assignments may also occur at L2, where the same MAC/NPA address is used to identify multiple Receivers [RFC4259]:
また、アドレス課題を重ね合わせるのはL2に起こるかもしれません:(そこでは、同じMAC/NPAアドレスが、複数のReceivers[RFC4259]を特定するのに使用されます)。
(i) An MAC/NPA unicast address must be unique within the
addressed area. The IEEE-assigned MAC addresses used in
Ethernet LANs are globally unique. If the addresses are not
globally unique, an address must only be re-used by
Receivers in different addressed (scoped) areas.
(i) MAC/NPAユニキャストアドレスは扱われた領域の中でユニークであるに違いありません。 イーサネットLANに使用されるIEEEによって割り当てられたMACアドレスはグローバルにユニークです。 アドレスがグローバルにユニークでないなら、Receiversは異なった扱われた(見られる)領域でアドレスを再使用するだけでよいです。
Fairhurst & Montpetit Informational [Page 11] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[11ページ]のRFC4947ARメカニズム
(ii) The MAC/NPA address broadcast address (a L2 address of all
ones). Traffic with this address should be confined to one
addressed area.
(ii) MAC/NPAは、放送演説が(すべてのもののa 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)の機会を導入します。 ReceiverがIPルータとして作動するとき、そのようなパケットの領収書は予期していなかったプロトコルのふるまいにつながることができます。
3.1. Unicast Support
3.1. ユニキャストサポート
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 Logical Channel(PID値)と対応するTS Multiplex(セクション4)に関連している必要があります。 MPEG-2Networkの中のそれぞれのEncapsulatorはそれが出典を明示するユニークなTS Logical Channels(PID値)[ETSI-DAT、RFC4259]の1セットに関連しています。 したがって、特定の範囲の中では、同じユニキャストIPアドレスは1Streamに関連しているかもしれません、そして、各Streamは異なった内容を寄付します(例えば、数個の異なったIP Encapsulatorsがいつ同じReceiverに運命づけられたIP流れを寄付しますか)。 また、MPEG-2Networksが、異なったReceiversか異なったTS Multiplexesを通して同じ内容(同時放送をされる)を送るためにIPパケットを模写するかもしれません。 Networkが、Receiverが受け入れるのを防がなければならない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アドレスを関連づける必要があります。
3.2. Multicast Support
3.2. マルチキャストサポート
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 Group Destination Address(セクション5.6)に特定のL2アドレスを関連づける際にネットワークレベルで起こります。 イーサネットの上のIPv4とIPv6でこれ
Fairhurst & Montpetit Informational [Page 12] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[12ページ]のRFC4947ARメカニズム
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)で起こらなければなりません。 このマルチキャストアドレス解決の目標はReceiverが特定のTS Logical Channelと対応するTS Multiplex[RFC4259]にIPv4かIPv6マルチキャストアドレスを関連づけるのを許容することです。 この協会は、多くの活動的なマルチキャストグループを可能にするのが必要であり、IPマルチキャストパケットをフィルターにかけて、進めるとき、Receiverで処理負荷を最小にするべきです(例えば、多くのTS Logical Channelsの上にマルチキャストトラフィックを分配することによって)。 ハードウェアフィルタリングを許容する体系は有益である場合があります、これらが求められていないマルチキャストトラフィックを捨てるのでドライバーとオペレーティングシステムを救うかもしれないので。
There are two specific functions required for address resolution in IP multicast over MPEG-2 Networks:
MPEG-2Networksの上にIPマルチキャストにはアドレス解決に必要である2つの具体的な機能があります:
(i) Mapping IP multicast groups to the underlying MPEG-2 TS Logical
Channel (PID) and the MPEG-2 TS Multiplex at the Encapsulator.
(i) IPマルチキャストを写像するのはEncapsulatorで基本的なMPEG-2TS Logical Channel(PID)とMPEG-2TS Multiplexに分類されます。
(ii) Provide signalling information to allow a Receiver to locate an
IP multicast flow within an MPEG-2 TS Multiplex.
(ii) ReceiverにMPEG-2TS Multiplexの中で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-2Networkがいくつかの論理的な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 Logical Channelsで利用可能であるときに、正しい動作を指定する必要があります。 異なったEncapsulatorsがASMの同じIP Group Destination Addressと共にIPパケットを寄付するとき、これが起こることができた、(いくらか、-、ソース、Multicast) 範囲を扱ってください。 Receiverがコピー1部以上の同じパケットを受けることができたとき(例えば、パケットはいつ異なったTS Logical Channelsか異なったTS Multiplexesさえ、Simulcastingとして知られているメソッドの向こう側に模写されますか[ETSI-DAT])、別のケースは起こります。 IPレベルでは、ホスト/ルータはこの複製に気づかないかもしれません、そして、これは他の手段で検出される必要があります。
When the MPEG-2 Network is peered to the multicast-enabled Internet, an arbitrarily large number of IP multicast group destination addresses may be in use, and the set forwarded on the transmission network may be expected to vary significantly with time. Some uses of IP multicast employ a range of addresses to support a single application (e.g., ND [RFC2461], Layered Coding Transport (LCT) [RFC3451], and Wave and Equation Based Rate Control (WEBRC) [RFC3738]). The current set of active addresses may be determined dynamically via a multicast group membership protocol (e.g., Internet
MPEG-2Networkがいつかがマルチキャストで可能にされたインターネットとしてじっと見ました、そして、任意に多くのIPマルチキャストグループ送付先アドレスが使用中であるかもしれません、そして、時間に従って送電網で進められたセットがかなり異なると予想されるかもしれません。 IPマルチキャストのいくつかの用途が、ただ一つのアプリケーションが(例えば、ノースダコタ[RFC2461]、Layered Coding Transport(LCT)[RFC3451]、Wave、およびEquation Based Rate Control(WEBRC)[RFC3738])であるとサポートするのにさまざまなアドレスを使います。 現在のアクティブなアドレスがマルチキャストグループ会員資格プロトコルでダイナミックに決定しているかもしれない、(例えば、インターネット
Fairhurst & Montpetit Informational [Page 13] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[13ページ]のRFC4947ARメカニズム
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.
Managementプロトコル(IGMP)[RFC3376]を分類してください。そうすれば、マルチキャストルーティング(例えば、プロトコル無党派Multicast(PIM)[RFC4601])、そして/または、しかしながら、他の手段(例えば、[RFC3819]と[RFC4605])、それぞれのアクティブなアドレスを通るMulticast Listenerディスカバリー(MLD)[RFC3810)はARメソッドで結合を必要とします。 したがって、明らかにそれぞれのIP交通の流れで付くARの広告を出す必要はありませんが、多くのL2 TS Logical Channelsの向こう側にトラフィックを分配できるメソッド(例えば、IPアドレスからMACアドレス[RFC1112、RFC2464]までマッピングに類似しているハッシュ/マッピングを使用する)を使用するのにおいて利点があります。 そのようなメソッドは、分配される必要があるAR情報のボリュームを減少させて、AR処理を抑えることができます。
Section 5.6 describes the binding of IP multicast addresses to MAC/NPA addresses.
セクション5.6はIPマルチキャストアドレスの製本についてMAC/NPAアドレスに説明します。
4. MPEG-2 Address Resolution
4. MPEG-2アドレス解決
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 Logical Channels[RFC4259])を特定すると合図しながら、このセクションの最初の部分はMPEG-2の役割について説明します。
At L2, the MPEG-2 Transport Stream [ISO-MPEG2] identifies the existence and format of a Stream, using a combination of two PSI tables: the Program Association Table (PAT) and entries in the program element loop of a Program Map Table (PMT). PMT Tables are sent infrequently and are typically small in size. The PAT is sent using the well-known PID value of 0X000. This table provides the correspondence between a program_number and a PID value. (The program_number is the numeric label associated with a program). Each program in the Table is associated with a specific PID value, used to identify a TS Logical Channel (i.e., a TS). The identified TS is used to send the PMT, which associates a set of PID values with the individual components of the program. This approach de-references the PID values when the MPEG-2 Network includes multiplexors or re- multiplexors that renumber the PID values of the TS Logical Channels that they process.
L2では、MPEG-2Transport Stream[ISO-MPEG2]はStreamの存在と形式を特定します、2個のPSIテーブルの組み合わせを使用して: Program Map Table(PMT)のプログラムの要素輪におけるProgram Association Table(PAT)とエントリー。 PMT Tablesはまれに送られて、サイズが通常小さいです。 PATに0×000のよく知られるPID値を使用させます。 このテーブルはプログラム_番号とPID値との通信を提供します。 (プログラム_数はプログラムに関連している数値ラベルです。) Tableのそれぞれのプログラムは特定のPID値に関連しています、とTS Logical Channel(すなわち、TS)は以前はよく特定していました。 特定されたTSは、PMTを送るのに使用されます。(PMTは1セットのPID値をプログラムの個々の部品に関連づけます)。 このMPEG-2であるのにPIDが評価するアプローチ反-参照Networkはマルチプレクサーか彼らが処理するTS Logical Channelsの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値がStreamに割り当てられている状態でReceiverに合図することに加えて、PMTエントリーは、MPEG-2送電網(マルチプレクサー、「再-マルチプレクサー」、レート整形器、広告挿入設備など)で作動するかもしれないデバイスのバラエティーにULEとMPEを使用することでStreamsの存在を示します。
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
マルチプレクサーか「再-マルチプレクサー」が、マルチプレクシングプロセスの間、Streamに関連している値、PMTエントリーに関連づけられないPID値を運ぶアップデートされたPMT. TS Packetsに反映される新しい値(孤児PID)が変えるPIDを変えるかもしれなくて、通常、ISO13818-1対応することのL2設備によって下げられるでしょう、中でなって
Fairhurst & Montpetit Informational [Page 14] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[14ページ]のRFC4947ARメカニズム
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).
送電網の向こう側に進められないStream。 どんな中間的デバイス(例えば、シナリオC、E、Fの[RFC4259])も使わないか、またはデバイスが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接頭語/アドレスにStreamを関連づけません。 セクションの残りはMPEG-2に関連するIPアドレス解決メカニズムについて説明します。
4.1. Static Configuration
4.1. 静的な構成
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アドレスか流れがどこで静的に特定のPIDsに写像されるかが、合図と同等物である、「外、-、バンド、」 アプリケーション・プログラマー、インストールしている技術者、またはユーザがMPEG-2TSに受け取るのではなく、外部が意味するいくつかを通してマッピングを受け取ります。 これはテスト、実験的なネットワーク、小さいサブネットワーク、および閉じているドメインの役に立ちます。
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値にアドレスに関連したというReceiver処理を最適化して、特定の範囲の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はこの専門化です。 現在のDOCSISケーブルモデム[DOCSIS]によってこの体系は使用されます。そこでは、すべてのIPトラフィックが指定されたTSストリームに置かれます。 MACフィルタリング(そして/または、MPEのセクションフィルタリング)は、サブネットワークを差別化するのに使用されるかもしれません。
4.1.1. MPEG-2 Cable Networks
4.1.1. MPEG-2つのケーブルネットワーク
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.
独身のよく知られているTS Logical Channel(PID)に送られたMPEG-2TS Packetsでカプセル化されたケーブルモデムにIP/イーサネットパケットを送ります(川下で)。 バンドにおける合図テーブルの無駄があります。 上流では、一般的なアプローチはMPEG-2の上でIP/イーサネットよりむしろイーサネット縁どりを使用することです、また、他の独占体系が、使用され続けていますが。
Fairhurst & Montpetit Informational [Page 15] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[15ページ]のRFC4947ARメカニズム
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.
ケーブルネットワークにおけるIPトラフィックのほとんどのアドレス解決体系は、DOCSISとEuroDOCSISの展開まで、独占であり、通常、テーブルベースのアドレス解決メソッドを使いませんでした。 独占メソッドは、いくつかの場合ケーブルモデムが相互作用を必要とするところで使用され続けています。 この場合、ギヤエンドの設備はケーブルモデムとインターネットの間のゲートウェイとして作動するかもしれません。 これらのゲートウェイは、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を使用します。 Cable Modem Terminal System(CMTS)はIPアドレスをDOCSISケーブルモデムに割り当てるDHCP Serverを供給します。MPEG-2送電網はケーブルモデム(セクション1)にネットワークであるとブリッジされたL2を供給します。 通常、これはIPデバイス[RFC2131]のためのDHCP Relay、[RFC3046]、および[RFC3256]として機能します。 IPv6の展開における問題は[RFC4779]で説明されます。
4.2. MPEG-2 Table-Based Address Resolution
4.2. MPEG-2のテーブルベースのアドレス解決
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.
SI/PSI Tablesを通してTS Multiplexの上まで運ばれたMPEG-2Transport Streamsのセットの情報を分配できます。 通常、定期的(セクション4)にこれらのテーブルを送ります。 [ETSI-SI1]、各Receiver[ETSI-SI]で、このデザインはSI Table情報をアクセスを必要として、処理します。 この体系はマルチメディアテレビに関連している様々なTransport Streamsを提供して、調整する複雑さを反映します。 TS Multiplexは、既存の制御卓と追加情報を統合するか、またはIPサービスに特定の追加SI Tablesを伝えることによって、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-2Receiverが特定のIPアドレスに関連している適切なPIDとマルチプレックスを特定できるMPEG-2Table用法に関する例は:
(i) IP/MAC Notification Table (INT) in the DVB Data standard
[ETSI-DAT]. This provides unidirectional address resolution of
IPv4/IPv6 multicast addresses to an MPEG-2 TS.
(i) DVB Data規格[ETSI-DAT]におけるIP/MAC Notification Table(INT)。 これはIPv4/IPv6マルチキャストアドレスの単方向のアドレス解決をMPEG-2TSに供給します。
(ii) Application Information Table (AIT) in the Multimedia Home
Platform (MHP) specifications [ETSI-MHP].
MultimediaホームPlatform(MHP)仕様[ETSI-MHP]による(ii)アプリケーション情報Table(AIT)。
(iii) Multicast Mapping Table (MMT) is an MPEG-2 Table employed by
some DVB-RCS systems to provide unidirectional address
resolution of IPv4 multicast addresses to an MPEG-2 TS.
(iii)マルチキャストMapping Table(MMT)はいくつかのDVB-RCSシステムによって使われた、IPv4マルチキャストアドレスの単方向のアドレス解決をMPEG-2TSに供給したMPEG-2Tableです。
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は特定のアプリケーションに使用されます。
Fairhurst & Montpetit Informational [Page 16] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[16ページ]のRFC4947ARメカニズム
4.2.1. IP/MAC Notification Table (INT) and Its Usage
4.2.1. IP/MAC通知テーブル(INT)とその用法
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ネットワークで番地を指定するために1セットの記述子を提供します。 このメソッドの使用はMultiprotocol Encapsulation(MPE)[ETSI-DAT]に指定されます。 それはDVBネットワークの中でIP/L2流れの位置の情報を運ぶためのメソッドを提供します。 Platform_IDはIP/L2ストリーム、そして/または、Receiversの1セットのためにアドレシング範囲を特定します。 Platformは1時までに運ばれた数個のTransport Streamsか複数のTS Multiplexesにかかるかもしれなくて、調和しているアドレス空間(範囲)でただ一つのIPネットワークを代表します。 これはMPEG-2Networkの中で数個の独立している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) _MAC_アドレス_記述子を狙ってください: MACアドレス(そして、それらのマスク)のシングルかセットについて説明する記述子。
(ii) target_MAC_address_range_descriptor: A descriptor that may be
used to set filters.
(ii) _MAC_アドレス_範囲_記述子を狙ってください: フィルタを設定するのに使用されるかもしれない記述子。
(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.
(iv)目標_IP_は_記述子をなでぎりします: IPv4接頭語の定義と発表を許します。
(v) target_IP_source_slash_descriptor: Uses source and destination
addresses to target a single or set of systems.
(v) _IP_ソース_スラッシュ_記述子を狙ってください: システムのシングルかセットを狙うのにソースと送付先アドレスを使用します。
(vi) IP/MAC stream_location_descriptor: A descriptor that locates an
IP/MAC stream in a DVB network.
(vi)IP/MACは_位置_記述子を流します: 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
目標_IPv6_アドレス_記述子目標_IPv6_スラッシュ_記述子と目標_IPv6_ソース_スラッシュ_記述子
Fairhurst & Montpetit Informational [Page 17] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[17ページ]のRFC4947ARメカニズム
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_アクセス_モード_記述子で、2番目のアドレス記述子の仕様は代替の非DVB(ことによると非IP)ネットワークを通してISPにアクセスできます。
One key benefit is that the approach employs MPEG-2 signalling (Section 4) and is integrated with other signalling information. This allows the INT to operate in the presence of (re)multiplexors [RFC4259] and to refer to PID values that are carried in different TS Multiplexes. This makes it well-suited to a Broadcast TV Scenario [RFC4259].
1つの主要な利益が、アプローチが(セクション4)に合図しながらMPEG-2を使うということであり、他の合図情報について統合しています。 これで、INTは(re)マルチプレクサー[RFC4259]があるとき作動して、異なったTS Multiplexesで運ばれるPID値について言及します。 これはそれをBroadcastに十分合っているテレビのScenario[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.
主要な欠点はEncapsulatorが関連PSI/SI MPEG-2制御情報を紹介する必要性です。 この制御情報は、Receiverに処理される必要があります。これはIP層の下で情報入手を必要とします。 プロトコル・スタックの中のこの処理の位置で、IP Policy、管理、およびセキュリティ機能に結果を関連づけるのは困難になります。 集中的管理の使用は、よりダイナミックな体系の実装を防ぎます。
4.2.2. Multicast Mapping Table (MMT) and Its Usage
4.2.2. マルチキャストマッピングテーブル(MMT)とその用法
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.
Multicast Mapping Table(MMT)は対応するPID値[MMT]に1セットのマルチキャストアドレスを関連づけるMPEG-2制御卓で運ばれるかもしれません。 このテーブルで、DVB-RCS Forward Link Subsystem(FLSS)は特定のTS Multiplexの中のPID値にIPv4とIPv6マルチキャストアドレスに関するマッピングを指定できます。 受信機(DVB-RCS Return Channel Satellite Terminals(RCSTs))は、それが受信するのを必要とするIPマルチキャスト流動に関連しているPID値を決定するのにこのテーブルを使用するかもしれません。 MMTはSatLabs Forum[MMT]によって指定されて、現在、DVB-RCS仕様の一部ではありません。
4.2.3. Application Information Table (AIT) and Its Usage
4.2.3. アプリケーション情報テーブル(オート麦)とその用法
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
DVB MultimediaホームPlatform(MHP)仕様[ETSI-MHP]は特定のAR機能を定義しません。 しかしながら、MHP Receiversにさまざまな制御情報を受け取らせるApplication情報Table(AIT)は定義されます。 AITはMPEG-2合図テーブルを使用します、データ放送の情報、放送ストリームによって運ばれたアプリケーションの必要な活性化状態などを提供して ブロードキャスターが、この情報からReceiverがアプリケーションの活性化状態を変えるよう要求できる、指示します。
Fairhurst & Montpetit Informational [Page 18] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[18ページ]のRFC4947ARメカニズム
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.
特定のマルチキャストパケット流れ(IPv4を使用するか、IPv6記述子)を受けるアプリケーション。 MHPの、ARは具体的な機能にもかかわらず、より広い構成とコントロール機能の一部が見られません。
4.2.4. Address Resolution in ATSC
4.2.4. ATSCでのアドレス解決
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-2Networkの中にIPパケットのトランスミッションを許容するシステムを定義します。 MPEG-2Program(PMTによって定義される)はIPマルチキャストストリーム[ATSC-A92]を含んでいる1つ以上のアプリケーション[ATSC-A90]を含むかもしれません。 値の0x0Dのストリーム_タイプインディケータを使用することでIPマルチキャストデータは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.
アプローチは送電網に役立つアプリケーションに焦点を合わせます。 IPマルチキャストメディアストリームと対応するSession記述プロトコル(SDP)発表ストリームを特定のMPEG-2Program Elementsに縛るのにMPEG-2SI Tablesを使用するメソッドは定義されます。 各アプリケーションは独立しているネットワークを構成します。 MPEG-2つのNetwork境界が範囲を扱うIPを設立します。
4.2.5. Comparison of SI/PSI Table Approaches
4.2.5. SI/ψテーブルアプローチの比較
The MPEG-2 methods based on SI/PSI meet the specified requirements of the groups that created them and each has their strength: the INT in terms of flexibility and extensibility, the MMT in its simplicity, and the AIT in its extensibility. However, they exhibit scalability constraints, represent technology specific solutions, and do not fully adopt IP-centric approaches that would enable easier use of the MPEG-2 bearer as a link technology within the wider Internet.
SI/PSIに基づくMPEG-2つのメソッドがそれらを作成したグループに関する規定要求事項を満たします、そして、それぞれには、それらの力があります: 柔軟性と伸展性に関するINT、簡単さのMMT、および伸展性におけるAIT。 しかしながら、彼らは、スケーラビリティ規制を示して、技術の特定の解決を表して、完全にリンク技術として、より広いインターネットの中でMPEG-2運搬人の、より簡単な使用を可能にするIP中心のアプローチを取るというわけではありません。
4.3. IP-Based Address Resolution for TS Logical Channels
4.3. t論理チャネルのための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-2Networksがマルチサービスネットワークになるように発展するのに従って、IPプロトコルの使用は、より一般的になっています。 ほとんどのMPEG-2Networksが現在、操作、コントロール、およびデータ配送にいくつかのIPプロトコルを使用します。 また、アドレス解決情報にIP輸送を使用させることができました。 これを書いている時点で、MPEG-2TSをサポートするどんな規格ベースの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:
TS Logical Channel(すなわち、Transport Stream)にIPアドレスを決議するのによく知られるIPマルチキャストアドレスの上でIPマルチキャストプロトコルを使用できたIP-レベルメソッドを定義する機会があります。 IPベースのアドレス解決を使用する利点は:
Fairhurst & Montpetit Informational [Page 19] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[19ページ]のRFC4947ARメカニズム
(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.
(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ベースのプロトコルは異なったネットワークシナリオの向こう側にMACアドレス・マッピングへのIPとTS Logical Channelsへのマッピングの両方(Streamに関連しているPID値)に共通方法を提供できます。
(iii) Extensibility:
IP-based AR mechanisms allow an independent evolution of the AR
protocol. This includes dynamic methods to request address
resolution and the ability to include other L2 information
(e.g., encryption keys).
(iii)伸展性: IPベースのARメカニズムはARプロトコルの独立している発展を許容します。 これはアドレス解決を要求するダイナミック方式と他のL2情報(例えば、暗号化キー)を含む能力を含んでいます。
(iv) Integration:
The information exchanged by IP-based AR protocols can easily
be integrated as a part of the IP network layer, simplifying
support for AAA, policy, Operations and Management (OAM),
mobility, configuration control, etc., that combine AR with
security.
(iv)統合: IPネットワーク層の一部として容易にIPベースのARプロトコルによって交換された情報は統合できます、AAA、方針、Operations、およびManagement(OAM)のサポート、移動性、ARをセキュリティに結合する構成管理などを簡素化して。
The drawbacks of an IP-based method include:
IPベースのメソッドの欠点は:
(i) It can not operate over an MPEG-2 Network that uses MPEG-2
remultiplexors [RFC4259] that modify the PID values associated
with the TS Logical Channels during the multiplexing operation
(Section 4). This makes the method unsuitable for use in
deployed broadcast TV networks [RFC4259].
(i) それはマルチプレクシング操作(セクション4)の間、TS Logical Channelsに関連しているPID値を変更するMPEG-2「再-マルチプレクサー」[RFC4259]を使用するMPEG-2Networkの上で作動できません。 これで、メソッドは配布している放送テレビのネットワーク[RFC4259]における使用に不適当になります。
(ii) IP-based methods can introduce concerns about the integrity of
the information and authentication of the sender [RFC4259].
(These concerns are also applicable to MPEG-2 Table methods,
but in this case the information is confined to the L2 network,
or parts of the network where gateway devices isolate the
MPEG-2 devices from the larger Internet creating virtual MPEG-2
private networks.) IP-based solutions should therefore
implement security mechanisms that may be used to authenticate
the sender and verify the integrity of the AR information as a
part of a larger security framework.
(ii)IPベースのメソッドは情報の保全と送付者[RFC4259]の認証に関する心配を導入できます。 (また、これらの関心もMPEG-2つのTableメソッドに適切ですが、ゲートウェイデバイスが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
IP-レベルメソッドはよく知られる(または、発見される)IPマルチキャストアドレスの上にAR Server(また、セクション5.4を見る)を実行するIPマルチキャストプロトコルを使用するかもしれません。 多くのシステム(セクション1)でスケーラビリティのための要件をネットワークに満たすために、単一のパケットは、複数のAR記録を輸送して、意図している範囲を定義する必要があります。
Fairhurst & Montpetit Informational [Page 20] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[20ページ]のRFC4947ARメカニズム
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アドレスがTS Logical Channels(例えば、イーサネットMACアドレス[RFC1112][RFC2464]へのIP Group Destination Addressesに関するマッピングと同様の論じ尽くすことのテクニック)の1セットに写像されることを許可するメソッドを使用するのも有益である場合があります。
5. Mapping IP Addresses to MAC/NPA Addresses
5. IPアドレスをMAC/NPAアドレスに写像します。
This section reviews IETF protocols that may be used to assign and manage the mapping of IP addresses to/from MAC/NPA addresses over MPEG-2 Networks.
このセクションはMPEG-2Networksの上のMAC/NPAアドレスからの/にIPアドレスに関するマッピングを割り当てて、管理するのに使用されるかもしれないIETFプロトコルを見直します。
An IP Encapsulator requires AR information to select an appropriate MAC/NPA address in the SNDU header [RFC4259] (Section 6). The information to complete this header may be taken directly from a neighbor/ARP cache, or may require the Encapsulator to retrieve the information using an AR protocol. The way in which this information is collected will depend upon whether the Encapsulator functions as a Router (at L3) or a Bridge (at L2) (Section 1.1).
IP Encapsulatorは、SNDUヘッダー[RFC4259](セクション6)で適切なMAC/NPAアドレスを選択するためにAR情報を必要とします。 このヘッダーを完成する情報は、直接隣人/ARPキャッシュから取るか、またはEncapsulatorが情報を検索するのをARプロトコルを使用することで必要とするかもしれません。 この情報が集められる方法はEncapsulatorがRouter(L3の)かBridge(L2の)(セクション1.1)として機能するかどうかによるでしょう。
Two IETF-defined protocols for mapping IP addresses to MAC/NPA addresses are the Address Resolution Protocol, ARP [RFC826], and the Neighbor Discovery protocol, ND [RFC2461], respectively for IPv4 and IPv6. Both protocols are normally used in a bidirectional mode, although both also permit unsolicited transmission of mappings. The IPv6 mapping defined in [RFC2464] can result in a large number of active MAC multicast addresses (e.g., one for each end host).
IPアドレスをMAC/NPAアドレスに写像するための2つのIETFによって定義されたプロトコルが、それぞれIPv4とIPv6のためのAddress Resolutionプロトコル、ARP[RFC826]とNeighborディスカバリープロトコル、ノースダコタ[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放送パケットに支持を要します。 多くのReceiversがARPトラフィックの比例している増加、帯域幅で限られたネットワークに関する心配に通じることができます。 また、トランスミッション遅れはプロトコル性能に影響を与えることができます。
ARP also has a number of security vulnerabilities. ARP spoofing is where a system can be fooled by a rogue device that sends a fictitious ARP RESPONSE that includes the IP address of a legitimate network system and the MAC of a rogue system. This causes legitimate systems on the network to update their ARP tables with the false mapping and then send future packets to the rogue system instead of the legitimate system. Using this method, a rogue system can see (and modify) packets sent through the network.
また、ARPには、多くのセキュリティの脆弱性があります。 ARPスプーフィングは正統のネットワーク・システムのIPアドレスと凶暴なシステムのMACを含んでいる架空のARP RESPONSEを送る凶暴なデバイスでシステムをだますことができるところです。 これは、ネットワークの正統のシステムが誤ったマッピングでそれらの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
安全なアルプ(SARP)は安全なトンネル(例えば、ワイヤレス・アクセスポイントかルータにおける各クライアントとサーバの間の)[RFC4346]を使用します。 ルータは安全なトンネルを使用するクライアントに関連づけられなかった少しのARP RESPONSEsも無視します。 正統のARP RESPONSEsだけが使用されています。
Fairhurst & Montpetit Informational [Page 21] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[21ページ]のRFC4947ARメカニズム
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は各クライアントでソフトウェアのインストールを必要とします。 それは標準の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.
ノースダコタプロトコルは1セットのIPマルチキャストアドレスを使用します。 各クライアントは制限されたセットのグループ送付先アドレスを通常聞くだけです、そして、大きいネットワーク多くのマルチキャストアドレスが使用されていますが、トラフィックは各グループではほとんど通常送られません。 したがって、MPEG-2NetworksのためのLayer2ARはスケーラブルな方法でこれをサポートしなければなりません。
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.
多くのノースダコタメッセージが非対称の操作を実行するのを求める大口需要を引き起こすかもしれません。 ベースノースダコタプロトコルは懇願へのマルチキャスト応答を送ることができるレートを制限します。 構成は、多くのReceiversで作動するとき、調整される必要があるかもしれません。
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]).
リンクRTTがイーサネットLANによって経験されるよりかなり大きいネットワークに使用されると、ノースダコタプロトコル[RFC2461]で指定されたデフォルトパラメタは相互運用性問題(例えばリンクRTT(往復の時間)が3秒を超えているとき決議する失敗)と性能退行(リンクRTT>1 2番目でノースダコタメッセージをコピーする)を紹介できます。 したがって、かなりの遅れ(.2セクション6.3[RFC2461])とのネットワークリンクを使用するとき、プロトコルパラメタ(例えば、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.
ノースダコタは同様のセキュリティの脆弱性をARPに持っています。 Secure Neighborディスカバリー(SEND)[RFC3971]は、ノースダコタ[RFC3756]で知られているセキュリティが脆弱性であると扱うために開発されました。 また、ノースダコタと比べて、それはARトラフィックを減少させることができます。 さらに、SENDは1ホストあたりのキーの構成を必要としないで、同じリンクにおけるSENDと不安定なノースダコタの両方の使用と共存できます。
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.
また、ノースダコタプロトコルはIPv6システムによって使用されて、アドレス解決を超えて他の機能を実行します、Router Solicitation/広告、Duplicate Address Detection(DAD)、Neighbor Unreachability Detection(NUD)、およびRedirectを含んでいて。 アドレス解決は必要でないときにさえ、これらの機能がホストの役に立ちます。
5.1. Unidirectional Links Supporting Unidirectional Connectivity
5.1. 単方向が接続性であるとサポートする単方向のリンク
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-2NetworksがリターンパスなしでUnidirectional Broadcast Link(UDL)を提供するかもしれません。 そのようなリンクは、リターンパス(例えば、UDPに基づいている)を必要としないユニキャストアプリケーションに使用されるかもしれませんが、IPマルチキャスト内容分配に一般的に使用されます。
Fairhurst & Montpetit Informational [Page 22] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[22ページ]のRFC4947ARメカニズム
/-----\
MPEG-2 Uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider + v MPEG-2 Downlink
+-----------+ |
+-----v------+
| MPEG-2 |
| Receiver |
+------------+
/-----MPEG-2MPEG-2円のアップリンク/円###の################(ネットワーク)#\/+----#------+ \--.--/ | ネットワーク| | | プロバイダー+v MPEG-2Downlink+-----------+ | +-----v------+ | MPEG-2| | 受信機| +------------+
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とノースダコタプロトコルは双方向の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.
したがって、単方向のリンクはEncapsulatorとReceiversで適切なAR情報を確立する別々のバンドで出ている構成メソッドを必要とします。 ULE[RFC4326]はMAC/NPAアドレスがSNDUから省略されるモードを定義します。 いくつかのシナリオでは、これはL2 ARの必要性をEncapsulatorに取り除くかもしれません。
5.2. Unidirectional Links with Bidirectional Connectivity
5.2. 双方向の接続性との単方向のリンク
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衛星通信とリターンリンクを使用するFeedリンクです。 このトポロジーは、Hybridネットワークとしてしばしば知られていて、非対称のネットワークルーティングを持っています。
/-----\
MPEG-2 uplink /MPEG-2 \
###################( Network )
# \ /
+----#------+ \--.--/
| Network | |
| Provider +-<-+ v MPEG-2 downlink
+-----------+ | |
| +-----v------+
+--<<--+ MPEG-2 |
Return | Receiver |
Path +------------+
/-----MPEG-2MPEG-2円のアップリンク/円###の################(ネットワーク)#\/+----#------+ \--.--/ | ネットワーク| | | MPEG-2ダウンリンク+に対するプロバイダー+<+-----------+ | | | +-----v------+ +--<<--+ MPEG-2| リターン| 受信機| 経路+------------+
Figure 4: Bidirectional connectivity
図4: 双方向の接続性
Fairhurst & Montpetit Informational [Page 23] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[23ページ]のRFC4947ARメカニズム
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).
Unidirectional Linkルート設定(UDLR)[RFC3077]プロトコルは、非対称のルーティングに関連している問題に打ち勝つのに使用されるかもしれません。 Dynamic Tunnel Configurationプロトコル(DTCP)はリターンパスの自動構成を可能にします。 UDLRは、L2で双方向の放送リンクを見習うL2トンネルメカニズムを提供することによって、IPと上側の層のプロトコルから単方向のルーティングを隠します。 UDLRを使用するネットワークはFeed RouterとすべてのReceiversが論理的なローカル・エリア・ネットワークを形成するトポロジーを持っています。 L2にフレームをカプセル化するのは、それらがインターネットPath(すなわち、ブリッジする)を通して送られるのを許容します。
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.
多くの単方向のリンクが前進の(給送)リンクに無線技術を使うので、Feedリンクの上にトラフィックを進めると関連しているかなりの費用があるかもしれません。 したがって、不要なトラフィック(例えばこれが含意するグループがそれのコントロールに転送されるマルチキャストのための)を進めるのを防ぐのはしばしば望ましいです。 また、(例えば、非対称の容量と損失[RFC3449])であるとリターン方向への推進の含意を考えなければなりません。 これはコントロールメッセージのボリュームと頻度を最小にする必要性を示します。
Three different AR cases may be identified (each considers sending an IP packet to a next-hop IP address that is not currently cached by the sender):
3つの異なったARケースが特定されるかもしれません(それぞれが、現在送付者によってキャッシュされない次のホップIPアドレスにIPパケットを送ると考えます):
(i) A Feed Router needs a Receiver MAC/NPA address.
(i) Feed RouterはReceiver 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).
Feed RouterがMAC/NPAアドレスが未知であるReceiverにFeed UDLを使用することでIPパケットを送るとき、これは起こります。 IPv4では、Feed RouterはReceiverのIPアドレスがあるARP REQUESTを送ります。IPを認識するReceiverはFeed Router(例えば、UDLRトンネルを使用する)のMAC/NPAアドレスにARP RESPONSEとの回答を扱います。 次に、Feed Routerは、IPがパケットであるとReceiverに関連しているユニキャストMAC/NPAアドレスに扱うかもしれません。また、ULEカプセル化形式は、パケットがこれが望ましいMAC/NPAアドレス(セクション6.1と6.5)を指定しないで送られることを許可します。
(ii) A Receiver needs the Feed Router MAC/NPA address.
(ii) ReceiverはFeed Router 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.
ReceiverがMAC/NPAアドレスが未知であるFeed RouterにIPパケットを送るとき、これは起こります。 IPv4では、ReceiverはFeed Router(例えば、UDLRトンネルを使用する)のIPアドレスがあるARP REQUESTを送ります。 ARP RESPONSEがFeed UDLを使用していて、Feed Routerは返答します。 そして、Receiverは、IPがパケットであると受取人のMAC/NPAアドレスに扱うかもしれません。
Fairhurst & Montpetit Informational [Page 24] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[24ページ]のRFC4947ARメカニズム
(iii) A Receiver needs another Receiver MAC/NPA address.
(iii) Receiverは別の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.
ReceiverがMAC/NPAアドレスが未知である別のReceiverにIPパケットを送るとき、これは起こります。 IPv4では、ReceiverはリモートReceiver(例えば、UDLRトンネルをFeed Routerに使用する)のIPアドレスがあるARP REQUESTを送ります。 Feed UDLの上に要求を転送します。 目標ReceiverはARP RESPONSE(例えば、UDLRトンネルを使用する)と共に返答します。 Feed RouterはUDLにおける応答を進めます。 そして、Receiverは、IPがパケットであると受取人のMAC/NPAアドレスに扱うかもしれません。
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にノースダコタプロトコルを使用することで実行されるかもしれません。
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、ノースダコタとSENDによって提供された反応アドレス解決手順の性能に影響を与えます。 イーサネットと対照して、解決が行われる間隔の間、AR Targetアドレスに扱われる多くのIPパケットを受け取るかもしれません。 ARP仕様で、インタフェースは解決要求への応答を待っている間、これらのパケットを捨てることができます。 しかしながら、適切に大きさで分けられたバッファはこの損失を防ぐでしょう。
In case (iii), the time to complete address resolution may be reduced by the use of an AR Server at the Feed (Section 5.4).
場合(iii)では、アドレス解決を終了する時間はFeed(セクション5.4)でAR Serverの使用で短縮されるかもしれません。
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 ServerへのL2の接続性は先の設立に要求されます。DHCPを使用するUDLRネットワークにリターンの接続性を確立する遅れ、DTCP HELLOメッセージの頻度を増強するのを有益にするかもしれません。 チューニングDHCPに関する詳細をセクション5.5に提供します。
5.3. Bidirectional Links
5.3. 双方向のリンク
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ネットワークは、あることができて、2MPEG-2トランスミッションリンクの組み合わせで構成されます。 通常、1個のリンクがリモートReceiversの1セットに食べさせる放送リンクです。 また、Receiversからリンクを提供するので、全二重としての結合したリンク機能は連結します。 この使用に関する例は両用DVB-S衛星中継とDVB-RCSシステムを含んでいます。
Fairhurst & Montpetit Informational [Page 25] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[25ページ]のRFC4947ARメカニズム
5.4. AR Server
5.4. ARサーバ
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.
MPEG-2NetworkのReceiversにAR情報を分配するのにAR Serverを使用できます。 いくらかのtopologiesでは、これはわざわざAR情報がReceiversによって発見されたかなり短縮するかもしれません。
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要求へのReceiversを代表して応じているプロキシとして作動できます。 IPv4 AR要求が受信されているとき(例えば、Receiver ARP REQUEST)、AR ServerはAR応答を送りながら、(プロキシ)で応じます、適切なIPをMAC/NPA結合に提供して(IPアドレスをL2アドレスに写像して)。
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.
また、Receiversで明白な要求の必要性なしでARP/隣人キャッシュをアップデートするのにマルチキャスト/放送を使用することでAR Serverで求められていない状態で情報を送るかもしれません。 求められていないメソッドは、大きいネットワークを計量しながら、向上できます。 複数のIPを縛るただ一つの放送/マルチキャストARメッセージとMAC/NPAアドレスを配布することによって、スケーリングをさらに改良できるでしょう。 これは、多くのクライアントと共に容量が消費したネットワークを減少させて、ネットワークでクライアント/サーバ処理を簡素化します。
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).
サブネットワークを構成することによってIETFによって定義されたプロトコルを使用することでAR Serverを実装することができるので、ReceiversからのAR RequestsはFeed/放送リンクに送るよりむしろ妨害されます。 妨害されたメッセージをAR Serverに送ります。AR Serverは1セットのMAC/NPAアドレス結合を維持します。 これらは構成されるか、またはReceiversによって送られたモニターしているARPメッセージによって学習されて、構成されるかもしれません。 現在定義されたIETFプロトコルは、メッセージ単位で付きながら、1つを許容するだけです(すなわち、L2帯域幅を保存するために、最適化は全くありません)。
Equivalent methods could provide IPv6 AR. Procedures for intercepting ND messages are defined in [RFC4389]. To perform an AR Server function, the AR information must also be cached. A caching AR proxy stores the system state within a middle-box device. This resembles a classic man-in-the-middle security attack; interactions with SEND are described in [SP-ND].
同等なメソッドはIPv6 ARを提供するかもしれません。 ノースダコタメッセージを傍受するための手順は[RFC4389]で定義されます。 また、AR Server機能を実行するために、AR情報をキャッシュしなければなりません。 キャッシュしているARプロキシは中央箱のデバイスの中にシステム状態を保存します。 これは古典的な中央の男性セキュリティー攻撃に類似しています。 SENDとの相互作用は[SP-ノースダコタ]で説明されます。
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データからキャッシュから追放するのに必要です。 また、Receiver結合が(例えば、IPの移動性、ネットワーク形態変化、または間欠Receiverの接続性)を変えることができるなら、キャッシュの一貫性も考えなければなりません。 これらの場合では、古い(聞き古した)情報の使用は不適当な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
現在のIETFによって定義されたメソッドは、IPアドレスの製本をMAC/NPAに供給しますが、MPEG-2Networksに適切な他のL2情報に結合を許しません、他のメソッドの使用を必要として
Fairhurst & Montpetit Informational [Page 26] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[26ページ]のRFC4947ARメカニズム
this function (Section 4). AR Servers can also be implemented using non-IETF AR protocols to provide the AR information required by Receivers.
この機能(セクション4)。 また、Receiversによって必要とされたAR情報を提供するのに非IETF ARプロトコルを使用することでAR Serversを実装することができます。
5.5. DHCP Tuning
5.5. DHCPチューニング
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-2Networksの上で双方向の接続性で使用されるかもしれません。 DHCPは2つのコンポーネントから成ります: DHCP ServerからDHCP Client(例えば、デフォルトルータ、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 ServersとDHCP Clientsの構成は地方のリンク周遊旅行遅れ(ことによると、ブリッジするのからの追加遅れ、例えば使用UDLRを含んでいる)を考慮に入れるべきです。 多くのクライアントがDHCPリース持続時間とアドレスプールのサイズを調整するのを望ましくすることができます。 また、適切なタイマ値は選択されるべきです: DHCPメッセージ再送タイムアウト、およびDHCP Serverが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 ClientsはDHCPメッセージを再送するかもしれません。 いくつかのクライアント実装がリースの有用性(ICMP Echo Requestによる)のチェックの満期の前にDHCPDISCOVER retransmissionに応じるために不十分な時間DHCP Serverに備えながら小さい(例えば、MPEG-2Networkに適切であるよりむしろイーサネット遅れに合っています)DHCPDISCOVERメッセージにタイムアウトを指定します、潜在的アドレス闘争をもたらして。 この値は、MPEG-2Networksのために調整される必要があるかもしれません。
5.6. IP Multicast AR
5.6. IPマルチキャストAR
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アドレス結合Group Destination Addressについて説明します。
In MPE [ETSI-DAT], a mapping is specified for the MAC Address based on the IP multicast address for IPv4 [RFC1112] and IPv6 [RFC2464]. (A variant of DVB (DVB-H) uses a modified MAC header [ETSI-DAT]).
MPE[ETSI-DAT]では、マッピングはIPv4[RFC1112]とIPv6[RFC2464]のためのIPマルチキャストアドレスに基づくマックーアドレスに指定されます。 (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アドレスが、任意であり、Receiverが効率的なL3マルチキャストアドレスフィルタリングを実行できるとき、必ず必要であるというわけではありません。 存在しているとき、マッピングはIPv4[RFC1112]とIPv6[RFC2464]のためのIPマルチキャストアドレスに基づいて定義されます。
Fairhurst & Montpetit Informational [Page 27] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[27ページ]のRFC4947ARメカニズム
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アドレスに写像される1つ以上の受信者IPアドレスをもたらすことができます。 Source特有のMulticast、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フィルタリングを実行できるReceiversに重要でないかもしれません。 セクション3は、MPEG-2Networkが、ネットワークとリンクレイヤで複数のアドレシングが範囲であるとサポートする必要であるかもしれないことに注意しました。 異なったTransport Streamsへの異なったグループの分離は1つの療法(PID値のマッピングにIPに合図する)です。 別のアプローチが[RFC1112]と[RFC2464]で定義されたものに代替のMAC/NPAマッピングを使うことですが、そのようなマッピングは、EncapsulatorとReceiverで一貫して制限されている必要があります、スケーラブルな方法でAR手順を用いて。
5.6.1. Multicast/Broadcast Addressing for UDLR
5.6.1. UDLRのためのマルチキャスト/ブロードキャスト・アドレッシング
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はLayer2ソリューションです。(Receiverはそれで次にFeed Router(図2でトポロジーを使用する)によってネイティブに進められて、起因しているReceiverのFeedインタフェースに最終的に受け取られるマルチキャスト/放送フレームを送るかもしれません)。このマルチキャスト推進は通常のL3 Reverse Path Forwarding(RPF)チェック、L2スパニングツリーチェック、IP Time To Live(TTL)分野の処理または行政上見られたマルチキャストアドレスのフィルタリングを含んでいません。 これは慎重にマルチキャストサポートを考える必要性を上げます。 進めるのを避けるのを輪にされます、Receiverが適切なフィルタ規則によって構成されて、付属ネットワークから発して、後でFeedリンクの上に受け取られるパケットを捨てるのを保証する必要があるというRFC3077メモ。
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ソースアドレスを含んでいるとき、再放送パケットは、リンクレイヤでReceiverにローカルであることのL2アドレスを捨てるフィルタを使用することでフィルターにかけられるかもしれません。いくつかの事情では、システムは未知(オールゼロ)のMACソースアドレス(例えば、IGMP Proxy Queriers[RFC4605])でパケットを送ることができます。(そこでは、L2のソースがReceiverで決定できません)。これらのパケットは、静かに捨てられる必要があります(関連サービスをReceiverに実行するのを防ぐかもしれません)。
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
いくつかのカプセル化形式もMAC/NPAソースアドレス(テーブル1)を含んでいません。 したがって、あるいはまた、それらのIPソースアドレスがローカルアイピーアドレス(または、アドレスの範囲)に合っているなら、マルチキャストパケットはIP層で捨てられるかもしれません。 システムはパケットを送ることができます。
Fairhurst & Montpetit Informational [Page 28] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[28ページ]のRFC4947ARメカニズム
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.
オールIPソースアドレス(例えば、BOOTP(プロトコルを独力で進みます)[RFC951]、DHCP[RFC2131]、およびノースダコタ[RFC2461])のゼロを合わせてください。(そこでは、L3のソースがこれらのパケットが静かに捨てられる必要があるReceiverで決定できません)。 これは、Receiver(例えば、IPv6 Duplicate Address DetectionかDHCPサーバを実行することへの参加)に関連サービスを実行するのを防ぐかもしれません。
6. Link Layer Support
6. リンクレイヤサポート
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.
このセクションは、リンクレイヤ(L2)がMPEG-2Networksでのアドレス解決のサポートであると考えます。 それは2冊を考えます: トランスミッションに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ネットワークに属す終わりのホストが異なった両立しないカプセル化メソッドを使うとき起こる問題を特定します。 したがって、Encapsulatorはただ一つのIPネットワークが(すなわち、同じサブネット放送演説か同じIPv6接頭語を共有するIPv4システムのセット)であるとサポートする1つのメソッド(例えば、ULEかMPE)だけを使用しなければなりません。 IPネットワークにおけるすべてのReceiversが放送(IPネットワークにおけるすべてのシステムに向けられる)か地方の範囲マルチキャストアドレス(セクション3)を使用するすべてのIPパケットを受けなければなりません。 これらのアドレスがあるパケットはサービス発見、IP AR、およびルーティング・プロトコルを含む多くのIPベースのプロトコルによって使用されます。 これらのパケットを受けないシステムは接続性失敗か不正確なふるまいを我慢できます(例えば、それらはIPベースの発見、構成、ルーティング、および発表プロトコルに参加できないかもしれません)。 このネットワークに向けられたユニキャストパケットに使用されるのと同じStreamを使用することでリンク地方のマルチキャストか放送パケットを伝えることによって、一貫した配送を確実にすることができます。 Receiverは同時に、1つ以上のL2 ARメカニズムを使用できました。 Receiverが同じ識別子のために2つの異なった結合を受けるとき、これは潜在的闘争を提示します。 複数のシステムが同じ識別子(例えば、Encapsulators)のための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では、ブリッジする形式は、正規モードと組み合わせてReceiverにパケットを扱うのに使用されるかもしれません(すべてのULE Receiversが両方のメソッドを実装するのに必要です)。 フレームがULE Bridgingモードを使用することでIPパケットを運んで、それで、送付先アドレスをReceiverのMACアドレスに対応するようにして、IPアドレスはReceiverインタフェースに対応するようになって、ReceiverのIPスタックに提供されるでしょう。また、すべてのブリッジしているIPマルチキャストと放送フレームはReceiverのIPスタックにコピーされるでしょう。
Fairhurst & Montpetit Informational [Page 29] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[29ページ]のRFC4947ARメカニズム
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].
受信機はReceiver[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 | +-------------------------------+--------+-------+-------+------+
+-------------------------------+--------+----------------------+ | | PDU|L2フレームヘッダーフィールド| | L2カプセル化|オーバーヘッド+----------------------+ | |[バイト]|src mac|dst mac| タイプ| +-------------------------------+--------+-------+-------+------+ |6.1 dst MACアドレスのないULE| 8 | - | - | x| |6.2 dst MACアドレスがあるULE| 14 | - | x| x| |6.3 LLC/スナップのないMPE| 16 | - | x| - | |6.4 LLC/スナップがあるMPE| 24 | - | x| x| |6.5 Bridging拡張子があるULE| 22 | x| x| x| |6.6 ブリッジするのがあるULEとNPA| 28 | x| x| x| |6.7 LLC/スナップとブリッジするのがあるMPE| 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を見てください)。
6.1. ULE without a Destination MAC/NPA Address (D=1)
6.1. 送付先MAC/NPAアドレスのないULE(D=1)
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の両方と共に使用されるかもしれません。 使用されると、Receiverがそれらの受信者IPアドレス[RFC4326]に基づくパケットのL3フィルタリングを実行すると予想されます。 これは、ReceiverがIPルータであるときに、ネットワーク形態の熟慮を必要とするか、またはIPルータにデータを提供します(これが受入れられる簡単なケースはReceiverの他のネットワークに接続性を全く持っていないスタッブネットワークの接続で起こります)。 MAC/NPAアドレスが全くSNDUにないので、ARPとノースダコタプロトコルは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ネットワーク・アドレスを構成できます。 自動構成を使用するのに、ReceiverのIPドライバーは、受信インタフェースのMAC/NPAアドレスにアクセスする必要があるかもしれません、この値が容認されたSNDUsをフィルターにかけるのに使用されていませんが。
Fairhurst & Montpetit Informational [Page 30] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[30ページ]のRFC4947ARメカニズム
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に使用されないと、ノースダコタプロトコルが、DAD、および他のIPv6がネットワーク層機能であるとサポートするのにまだ必要であるかもしれません。 このプロトコルは1ブロックのIPv6マルチキャストアドレスを使用します。(アドレスは、L2ネットワークによって運ばれる必要があります)。 それは、元々、それ自体で送られて、形式がMACソースアドレスを提供しないこのカプセル化以来topologies(例えば、セクション5.6.1)がシステムがDADパケットを差別化できないところにどのようにあっても、います。別のシステムによって送られたかもしれないものから、同じL3アドレスで、再放送します。 したがって、このL2推進が起こるかもしれないtopologiesのこのカプセル化形式と共にDADを使用できません。
6.2. ULE with a Destination MAC/NPA Address (D=0)
6.2. 送付先MAC/NPAアドレスがあるULE(D=0)
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 Address Resolutionプロトコル(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ノースダコタプロトコルはサポートされます。 プロトコルは1ブロックのIPv6マルチキャストアドレスを使用します。(アドレスは、L2ネットワークによって運ばれる必要があります)。 プロトコルは1ブロックのIPv6マルチキャストアドレスを使用します。(アドレスは、L2ネットワークによって運ばれる必要があります)。 それは、元々、それ自体で送られて、形式がMACソースアドレスを提供しないこのカプセル化以来topologies(例えば、セクション5.6.1)がシステムがDADパケットを差別化できないところにどのようにあっても、います。別のシステムによって送られたかもしれないものから、同じL3アドレスで、再放送します。 したがって、このL2推進が起こるかもしれないtopologiesのこのカプセル化形式と共にDADを使用できません。
6.3. MPE without LLC/SNAP Encapsulation
6.3. LLC/スナップカプセル化のないMPE
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 Encapsulatorsによって指定されたデフォルトと(時々唯一)のモードです。 MPEは、EtherType野原を供給しないで、したがって、Address Resolutionがプロトコル(ARP)[RFC826]であるとサポートすることができません。
IPv6 is not supported in this encapsulation format, and therefore it is not appropriate to consider the ND protocol.
IPv6はこのカプセル化形式でサポートされません、そして、したがって、ノースダコタプロトコルを考えるのは適切ではありません。
6.4. MPE with LLC/SNAP Encapsulation
6.4. LLC/スナップカプセル化があるMPE
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(サブNetwork Accessプロトコル)形式は、EtherType野原を供給して、したがって、ARP[RFC826]をサポートするかもしれません。 これがどう実行されるかを定義するために、仕様は全くありません。 どんなMACソースアドレスもSNDUに存在していません、プロトコルがそれが生成するどんな質問メッセージのARPの記録的なペイロードのソースMACアドレスも伝えますが。
Fairhurst & Montpetit Informational [Page 31] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[31ページ]のRFC4947ARメカニズム
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ノースダコタプロトコルは、MPEのLLC/SNAP形式を使用することでサポートされます。 これは、特定のマルチキャストアドレスがL2ネットワークによって運ばれるのを必要とします。 IPv6ノースダコタプロトコルはサポートされます。 プロトコルは1ブロックのIPv6マルチキャストアドレスを使用します。(アドレスは、L2ネットワークによって運ばれる必要があります)。 それは、元々、それ自体で送られて、形式がMACソースアドレスを提供しないこのカプセル化以来topologies(例えば、セクション5.6.1)がシステムがDADパケットを差別化できないところにどのようにあっても、います。別のシステムによって送られたかもしれないものから、同じL3アドレスで、再放送します。 したがって、このL2推進が起こるかもしれないtopologiesのこのカプセル化形式と共にDADを使用できません。
6.5. ULE with Bridging Header Extension (D=1)
6.5. ヘッダーに拡大をブリッジするULE(D=1)
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)なしでこれを使用できます。 他のどんなExtension HeadersもこのExtensionに先行しないと、MAC送付先アドレスはNPA送付先アドレスに使用されるそれとしてULE SNDUに同じ位置を持っています。 Receiverが任意に構成されるかもしれないので、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).
Encapsulatorでは、ULE MAC/NPA送付先アドレスはL2推進決定で決定します。 容認されたフレームを送るか、またはReceiver自身に扱うかもしれません。 他のL2LANのように、Receiverは、構成されたMAC目的地アドレスフィルタに基づく容認されたフレームをフィルターにかけるのを選ぶかもしれません。 ARPとノースダコタメッセージはこのカプセル化形式によってブリッジされるPDUの中で伝えられるかもしれません。 トポロジーが元々Receiver(例えば、セクション5.6.1)によって送られたマルチキャストフレームの再放送コピーのその後のレセプションをもたらすかもしれないところでは、システムはそれが同じインタフェース[802.1D]から送られたフレームで使用したソースアドレスで受け取られるフレームを捨てなければなりません。 これはブリッジしているネットワークで複製を防ぎます(そうでなければ、例えば、これはDADを呼び出すでしょう)。
6.6. ULE with Bridging Header Extension and NPA Address (D=0)
6.6. ヘッダー拡大とNPAがアドレスであるとブリッジするULE(D=0)
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送付先アドレス(すなわち、Receiver 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
Encapsulatorでは、ULE MAC/NPA送付先アドレスの値はL2推進決定で決定します。 Receiverでは、フレームを送るか、またはReceiver自身に扱うかもしれません。 他のL2LANのように、Receiverは、構成されたMAC目的地アドレスフィルタに基づく容認されたフレームをフィルターにかけるのを選ぶかもしれません。 ARPとノースダコタメッセージはこれによってブリッジされるPDUの中で伝えられるかもしれません。
Fairhurst & Montpetit Informational [Page 32] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[32ページ]のRFC4947ARメカニズム
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).
カプセル化形式。 トポロジーがどこでその後のレセプションをもたらすかもしれないかがマルチキャストフレームのコピーを再放送して、それは元々Receiver(例えば、セクション5.6.1)によって送られて、システムはそれが同じインタフェース[802.1D]から送られたフレームで使用したソースアドレスで受け取られるフレームを捨てなければなりません。 これはブリッジしているネットワークで複製を防ぎます(そうでなければ、例えば、これはDADを呼び出すでしょう)。
6.7. MPE with LLC/SNAP & Bridging
6.7. LLC/スナップとブリッジするのがあるMPE
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フレームは任意にヘッダー[LLC]をブリッジするIEEEをサポートするかもしれません。 このヘッダーは、より大きいカプセル化オーバーヘッドを犠牲にしてソースと送付先MACアドレスの両方を供給します。 形式は2つのMAC送付先アドレス(ブリッジしているMACフレーム(すなわち、リモートLANにおける意図している受取人のMACアドレス)でMPE SNDU(すなわち、Receiver MACアドレス)と1つに関連づけられたもの)を定義します。
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).
Encapsulatorでは、MPE MAC送付先アドレスはL2推進決定で決定します。 現在、このカプセル化形式のためのReceiver処理の形式的記述が全くありません。 Receiverがフレームを送るかもしれませんか、またはそれらはReceiver自身に扱われるかもしれません。 他のL2LANのように、Receiverは、構成されたMAC目的地アドレスフィルタに基づく容認されたフレームをフィルターにかけるのを選ぶかもしれません。 ARPとノースダコタメッセージはこのカプセル化形式によってブリッジされるPDUの中で伝えられるかもしれません。 MPE MAC送付先アドレスはL2推進決定で決定します。 トポロジーがどこでその後のレセプションをもたらすかもしれないかがマルチキャストフレームのコピーを再放送して、それは元々Receiver(例えば、セクション5.6.1)によって送られて、システムはそれが同じインタフェース[802.1D]から送られたフレームで使用したソースアドレスで受け取られるフレームを捨てなければなりません。 これはブリッジしているネットワークで複製を防ぎます(そうでなければ、例えば、これはDADを呼び出すでしょう)。
7. Conclusions
7. 結論
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.
このドキュメントは、扱うと説明します、そして、IPプロトコルのためにMPEG-2つの送電網の上でワイヤードなものと同様にワイヤレスの技術を使用することで解決問題を扱ってください。 MPEG-2つの送電網の上の彼らの予想されたふるまいと共に多くの特定のIETFプロトコルについて議論します。 それらの用法のための推薦を提供します。
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,
すべてのMPEG-2Networksで使用されるどんなただ一つの一般的なアプローチもありません。 静的な結合はIPアドレスとPIDsのために構成されるかもしれません(いくつかのケーブルネットワークのように)。 この情報が放送網では、通常、Encapsulator/マルチプレクサーによって提供されて、合図テーブルで運ばれる、(例えば、MHPのAIT、IP Notification Table、INT
Fairhurst & Montpetit Informational [Page 33] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[33ページ]のRFC4947ARメカニズム
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.
DVB、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プロトコル・スタックのサポートを改良するという推薦で。
8. Security Considerations
8. セキュリティ問題
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.
現在、PSI/SIテーブル(セクション4)を使用しながら、制御飛行機での情報の(周期的)の放送でMPEG-2つの送電網で合図するL2を提供します。 SI情報の損失か変更がサービスに使用されるTS Logical Channel(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]の使用に関連する安全保障問題が知られています。 また、IPを写像するのがアドレスがARP[RFC826]を使用して、ノースダコタであるとMAC/NPAに扱うとき[RFC2461]、読者は知られている安全保障問題を参照されます。 そのARプロトコルサポートはARメッセージの源の認証とAR情報の保全、これがL2インフラストラクチャの中に権限のないARメッセージの挿入から生じる知られているセキュリティの脆弱性を避けることが勧められます。 IPv6のために、SENDプロトコル[RFC3971]はノースダコタに代わって使用されるかもしれません。 これはARを保護できるセキュリティー対策を定義します。
AR protocols can also be protected by the use of L2 security methods (e.g., Encryption of the ULE SNDU [IPDVB-SEC]). When these methods are used, the security of ARP and ND can be comparable to that of a private LAN: A Receiver will only accept ARP or ND transmissions from the set of peer senders that share a common group encryption and common group authentication key provided by the L2 key management.
また、L2セキュリティメソッド(例えば、ULE SNDU[IPDVB-SEC]のEncryption)の使用でARプロトコルを保護できます。 これらのメソッドが使用されているとき、ARPとノースダコタのセキュリティは個人的なLANのものに匹敵している場合があります: ReceiverはL2かぎ管理によって提供された一般的なグループ暗号化と一般的なグループ認証キーを共有する同輩送付者のセットからARPかノースダコタのトランスミッションを受け入れるだけでしょう。
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
AR Servers(セクション5.4)は、unsecured ARを使用することで終わりのホストへの同じ種類の安全保障問題に影響されやすいです。 これらの問題は、サブネットの中でトラフィックとサービスの否定をハイジャックするのを含んでいます。 サブネットの中の悪意があるノードは、この特性を利用して、トラフィックをハイジャックできます。 さらに、AR Serverは本質的には中央の正統の男性です。(その男性は求められていない中央の男性攻撃者とそのようなプロキシを区別する必要があると暗示します)。 このドキュメントはどんな新しいメカニズムも紹介しません。
Fairhurst & Montpetit Informational [Page 34] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[34ページ]のRFC4947ARメカニズム
protection of these AR functions (e.g., authenticating servers, or defining AR Servers that interoperate with the SEND protocol [SP-ND]).
これらのAR機能(例えば、サーバを認証するか、またはSENDプロトコル[SP-ノースダコタ]で共同利用するAR Serversを定義する)の保護。
9. Acknowledgments
9. 承認
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).
作者は特に彼らの入力、Rodウォルシュ、Jun武井、およびマイケルMercurioについてIPDVB WGメンバーに感謝したがっています。 また、作者は欧州宇宙機関のサポートを承諾します。 マーチンStiemerlingはシナリオの記述、構成を寄付して、大規模なプルーフ・リーディングを提供しました。 Hidetaka IzumiyamaはUDLRとIPv6問題で貢献しました。 また、UDLRワーキンググループで議論した多くの問題がこのドキュメント(「RFC3077との実験」、2003年7月に、まとめられる)に貴重な入力を供給しました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[ETSI-DAT] EN 301 192, "Specifications for Data Broadcasting",
v1.3.1, European Telecommunications Standards Institute
(ETSI), May 2003.
[ETSI-DAT] EN301 192、「データ・ブロードキャスティングのための仕様」、v1.3.1、ヨーロッパのTelecommunications Standards Institute(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]t101 812、「(DVB)を放送するデジタルビデオ」。 「マルチメディアホームPlatform(MHP)仕様」、v1.2.1、ヨーロッパのTelecommunications Standards Institute(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] アン300 468、「(DVB)を放送するデジタルビデオ」。 「DVBシステムのService情報(SI)のための仕様」、v1.7.1、ヨーロッパのTelecommunications Standards Institute(ETSI)、2005年12月。
[ISO-MPEG2] ISO/IEC IS 13818-1, "Information technology -- Generic
coding of moving pictures and associated audio
information -- Part 1: Systems", International
Standards Organization (ISO), 2000.
[ISO-MPEG2]ISO/IECが13818-1である、「情報技術--映画と関連オーディオ情報のジェネリックコード化--第1部:、」 「システム」、世界規格組織(ISO)、2000。
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit
Ethernet Address for Transmission on Ethernet
Hardware", STD 37, RFC 826, November 1982.
[RFC826] プラマー、D.、「イーサネットアドレス決議は以下について議定書の中で述べます」。 「または、ネットワーク・プロトコルを変換するのは、イーサネットハードウェアの上でイーサネットがトランスミッションのためのアドレスであると48.bitに扱う」STD37、RFC826、1982年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD
5, RFC 1112, August 1989.
[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
Fairhurst & Montpetit Informational [Page 35] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[35ページ]のRFC4947ARメカニズム
[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)のための隣人発見」、RFC2461、1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[RFC2464] クロフォード、M.、「イーサネットネットワークの上のIPv6パケットのトランスミッション」、RFC2464、1998年12月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、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.チャン、「単方向の間のリンクレイヤトンネリングメカニズムはリンクします」、RFC3077、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP) Service for IPv6", RFC 3736, April
2004.
[RFC3736] Droms、R.「(DHCP)がIPv6"、RFC3736年のために修理する状態がないダイナミックなホスト構成プロトコル、2004年4月」。
[RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
Lightweight Encapsulation (ULE) for Transmission of IP
Datagrams over an MPEG-2 Transport Stream (TS)", RFC
4326, December 2005.
[RFC4326] Fairhurst、G.、およびB.Collini-ノッカー、「MPEG-2の上のIPデータグラム輸送の送信のための単方向のライト級カプセル化(ULE)は(ts)を流します」、RFC4326、2005年12月。
10.2. Informative References
10.2. 有益な参照
[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] IEEE802.3、「地方とメトロポリタンエリアネットワーク決められた一定の要求Part3:」 「衝突検出(CSMA/CD)アクセス法と物理的な層の仕様がある搬送波感知多重アクセス」、IEEEコンピュータSociety、(ISO/IEC8802-3も)、2002。
[ATSC] A/53C, "ATSC Digital Television Standard", Advanced
Television Systems Committee (ATSC), Doc. A/53C, 2004.
[ATSC] Doc、「ATSCのデジタルテレビジョン標準規格」という/53Cはテレビジョン方式委員会(ATSC)を進めました。 /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] /54A、「ATSC Digital Television Standardの使用へのガイド」、Advanced Television Systems Committee(ATSC)、Doc。 /54A、2003。
[ATSC-A90] A/90, "ATSC Data Broadcast Standard", Advanced
Television Systems Committee (ATSC), Doc. A/90, 2000.
[ATSC-A90] Doc、「ATSCデータ放送規格」という/90はテレビジョン方式委員会(ATSC)を進めました。 /90、2000。
Fairhurst & Montpetit Informational [Page 36] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[36ページ]のRFC4947ARメカニズム
[ATSC-A92] A/92, "Delivery of IP Multicast Sessions over ATSC
Data Broadcast", Advanced Television Systems Committee
(ATSC), Doc. A/92, 2002.
[ATSC-A92] Doc、「ATSCデータの上のIPマルチキャストセッションの配送は放送した」という/92はテレビジョン方式委員会(ATSC)を進めました。 /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]「データ過剰ケーブルサービスインターフェース仕様、DOCSIS2.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).
[ETSI-DVBS]アン301 421、「(DVB)を放送するデジタルビデオ」。 「11/12ギガヘルツにおけるDBSサテライト・システムのための変調とCoding」、ヨーロッパのTelecommunications Standards Institute(ETSI)。
[ETSI-RCS] EN 301 790, "Digital Video Broadcasting (DVB);
Interaction channel for satellite distribution
Systems", European Telecommunications Standards
Institute (ETSI).
[ETSI-RCS]アン301 790、「(DVB)を放送するデジタルビデオ」。 「衛星分配Systemsのための相互作用チャンネル」、ヨーロッパのTelecommunications Standards Institute(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]TR101 162、「(DVB)を放送するデジタルビデオ」。 「DVBシステムのためのService情報(SI)コードの配分」、ヨーロッパのTelecommunications Standards Institute(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.ピッライ、「Unidirectionalライト級Encapsulation(ULE)のためのセキュリティ要件は議定書を作ります」、ProgressのWork、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 「情報技術(映画と関連オーディオ情報のジェネリックコード化)は6を分ける」ということです。 「DSM-CCのための拡大は完全なソフトウェア実行です」、国際Standards Organization(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/IEC8802.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_システム推薦_v2.0_general.pdf。
Fairhurst & Montpetit Informational [Page 37] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[37ページ]のRFC4947ARメカニズム
[RFC951] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC
951, September 1985.
[RFC951] 耕地とW.とJ.ギルモア、「プロトコルを独力で進んでください」、RFC951、1985年9月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP
23, RFC 2365, July 1998.
[RFC2365] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998.
[RFC2375] HindenとR.とS.デアリング、「IPv6マルチキャストアドレス課題」、RFC2375、1998年7月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[RFC3046] パトリック、M.、「DHCP中継エージェント情報オプション」、RFC3046、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(Dynamic Host Configuration Protocol)はエージェント情報サブオプションをリレーします」、RFC3256、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インチ、RFC3376、2002年10月。」
[RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and
M. Sooriyabandara, "TCP Performance Implications of
Network Path Asymmetry", BCP 69, RFC 3449, December
2002.
[RFC3449] Balakrishnan、H.、Padmanabhan、V.、Fairhurst、G.、およびM.Sooriyabandara、「ネットワーク経路非対称のTCPパフォーマンス含意」、BCP69、RFC3449(2002年12月)。
[RFC3451] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L.,
Handley, M., and J. Crowcroft, "Layered Coding
Transport (LCT) Building Block", RFC 3451, December
2002.
[RFC3451]Luby(M.、Gemmell、J.、Vicisano、L.、リゾー、L.、ハンドレー、M.、およびJ.クロウクロフト)は「コード化輸送(LCT)ブロックを層にしました」、RFC3451、2002年12月。
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3569]Bhattacharyya、2003年7月のS.、「ソース特有のマルチキャスト(SSM)の概要」RFC3569。
[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隣人発見(ノースダコタ)信頼モデルと脅威」(RFC3756)は2004がそうするかもしれません。
[RFC3738] Luby, M. and V. Goyal, "Wave and Equation Based Rate
Control (WEBRC) Building Block", RFC 3738, April 2004.
Goyal、[RFC3738]Luby、M.、およびRFC3738、2004年4月対「波と方程式のベースの速度制御(WEBRC)ブロック」
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
そして、[RFC3810]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
Fairhurst & Montpetit Informational [Page 38] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[38ページ]のRFC4947ARメカニズム
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and
L. Wood, "Advice for Internet Subnetwork Designers",
BCP 89, RFC 3819, July 2004.
[RFC3819]KarnとP.とボルマンとC.とFairhurstとG.とグロースマンとD.とラドウィグとR.とMahdaviとJ.とモンテネグロとG.と接触、J.とL.木、「インターネットサブネットワークデザイナーのためのアドバイス」BCP89、RFC3819(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、「安全な隣人発見(発信する)」、RFC3971、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.、「セキュリティが有効搭載量であるとカプセル化する中のRSA/SHA-1署名(超能力)と認証ヘッダー(ああ)の使用」、RFC4359(2006年1月)。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer
Security (TLS) Protocol Version 1.1", RFC 4346, April
2006.
[RFC4346] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor
Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389] ターレル、D.、Talwar、M.、およびC.パテル、「隣人発見プロキシ(第プロキシ)」、RFC4389、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):、」 「プロトコル仕様(改訂される)」、RFC4601、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 Proxying")について議定書の中で述べます」、RFC4605、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.殻、「広帯域アクセスネットワークにおけるISP IPv6展開シナリオ」、RFC4779(2007年1月)。
[RFC4840] Aboba, B., Davies, E., and D. Thaler, "Multiple
Encapsulation Methods Considered Harmful", RFC 4840,
April 2007.
2007年4月の[RFC4840]AbobaとB.とデイヴィース、E.とD.ターレル、「有害であると考えられた複数のカプセル化方法」RFC4840。
[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-ノースダコタ] 「プロキシ隣人発見問題声明を保証し」て、デイリー、G.は進歩、2005年2月に働いています。
Fairhurst & Montpetit Informational [Page 39] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[39ページ]のRFC4947ARメカニズム
Authors' Addresses
作者のアドレス
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen, AB24 3UE UK
アバディーンアバディーンのGodred Fairhurst工学部大学、AB24 3UEイギリス
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モトローラのコネクテッドホーム解決はTechnology55Haydenアベニュー、第3Floorレキシントン、マサチューセッツ02421米国を進めました。
EMail: mmontpetit@motorola.com
メール: mmontpetit@motorola.com
Fairhurst & Montpetit Informational [Page 40] RFC 4947 AR Mechanisms for IP over MPEG-2 Networks July 2007
MPEG-2つのネットワーク2007年7月の上のIPのためのFairhurst&Montpetitの情報[40ページ]のRFC4947ARメカニズム
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Fairhurst & Montpetit Informational [Page 41]
Fairhurst&Montpetit情報です。[41ページ]
一覧
スポンサーリンク
