Network Working Group P. Savola
Request for Comments: 5110 CSC/FUNET
Category: Informational January 2008
Overview of the Internet Multicast Routing Architecture
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
This document describes multicast routing architectures that are currently deployed on the Internet. This document briefly describes those protocols and references their specifications.
この文書は、現在、インターネット上に展開されているマルチキャストルーティングアーキテクチャについて説明します。この文書では、簡単にこれらのプロトコルを記述し、その仕様を参照します。
This memo also reclassifies several older RFCs to Historic. These RFCs describe multicast routing protocols that were never widely deployed or have fallen into disuse.
また、このメモは歴史的に、いくつかの古いRFCを再分類します。これらのRFCは、広く展開されなかったまたは廃止に陥っているマルチキャストルーティングプロトコルを記述します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Multicast-Related Abbreviations ............................4
2. Multicast Routing ...............................................4
2.1. Setting up Multicast Forwarding State ......................5
2.1.1. PIM-SM ..............................................5
2.1.2. PIM-DM ..............................................5
2.1.3. Bidirectional PIM ...................................6
2.1.4. DVMRP ...............................................6
2.1.5. MOSPF ...............................................7
2.1.6. BGMP ................................................7
2.1.7. CBT .................................................7
2.1.8. Interactions and Summary ............................7
2.2. Distributing Topology Information ..........................8
2.2.1. Multiprotocol BGP ...................................8
2.2.2. OSPF/IS-IS Multi-Topology Extensions ................9
2.2.3. Issue: Overlapping Unicast/Multicast Topology .......9
2.2.4. Summary ............................................10
2.3. Learning (Active) Sources .................................10
2.3.1. SSM ................................................11
2.3.2. MSDP ...............................................11
2.3.3. Embedded-RP ........................................11
2.3.4. Summary ............................................12
2.4. Configuring and Distributing PIM RP Information ...........12
2.4.1. Manual RP Configuration ............................12
2.4.2. Embedded-RP ........................................13
2.4.3. BSR and Auto-RP ....................................13
2.4.4. Summary ............................................14
2.5. Mechanisms for Enhanced Redundancy ........................14
2.5.1. Anycast RP .........................................14
2.5.2. Stateless RP Failover ..............................14
2.5.3. Bidirectional PIM ..................................15
2.5.4. Summary ............................................15
2.6. Interactions with Hosts ...................................15
2.6.1. Hosts Sending Multicast ............................15
2.6.2. Hosts Receiving Multicast ..........................15
2.6.3. Summary ............................................16
2.7. Restricting Multicast Flooding in the Link Layer ..........16
2.7.1. Router-to-Router Flooding Reduction ................16
2.7.2. Host/Router Flooding Reduction .....................17
2.7.3. Summary ............................................18
3. Acknowledgements ...............................................18
4. IANA Considerations ............................................18
5. Security Considerations ........................................19
6. References .....................................................19
6.1. Normative References ......................................19
6.2. Informative References ....................................20
Appendix A. Multicast Payload Transport Extensions.................24
A.1. Reliable Multicast.........................................24
A.2. Multicast Group Security...................................24
This document provides a brief overview of multicast routing architectures that are currently deployed on the Internet and how those protocols fit together. It also describes those multicast routing protocols that were never widely deployed or have fallen into disuse. A companion document [ADDRARCH] describes multicast addressing architectures.
この文書は、現在、インターネット上に展開し、どのようにこれらのプロトコルが一緒にフィットしているマルチキャストルーティングアーキテクチャの概要を説明します。また、広く展開されなかったまたは廃止に陥っているこれらのマルチキャストルーティングプロトコルについて説明します。仲間ドキュメントは[ADDRARCH]マルチキャストアドレス指定のアーキテクチャについて説明します。
Specifically, this memo deals with:
具体的には、このメモはを扱います：
o setting up multicast forwarding state (Section 2.1),
マルチキャスト転送状態を設定O（2.1節）
o distributing multicast topology information (Section 2.2),
マルチキャストトポロジ情報（セクション2.2）を分配O、
o learning active sources (Section 2.3),
O、アクティブソース（2.3節）を学びます
o configuring and distributing the rendezvous point (RP) information (Section 2.4),
ランデブーポイント（RP）情報（2.4節）を構成し、配布するO、
o mechanisms for enhanced redundancy (Section 2.5),
拡張冗長性のためにOメカニズム（セクション2.5）、
o interacting with hosts (Section 2.6), and
ホスト（セクション2.6）との相互作用、およびo
o restricting the multicast flooding in the link layer (Section 2.7).
リンク層（2.7節）でマルチキャストフラッディングを制限するO。
Section 2 starts by describing a simplistic example how these classes of mechanisms fit together. Some multicast data transport issues are also introduced in Appendix A.
第メカニズムのこれらのクラスが一緒にどのように適合するか単純化した例を説明することによって2つの開始。いくつかのマルチキャストデータ転送の問題も付録Aに導入されています
This memo reclassifies to Historic [RFC2026] the following RFCs:
このメモは、歴史的な[RFC2026]、次のRFCに再分類します：
o Border Gateway Multicast Protocol (BGMP) [RFC3913],
Oボーダーゲートウェイマルチキャストプロトコル（BGMP）[RFC3913]、
o Core Based Trees (CBT) [RFC2189] [RFC2201],
Oコアベースツリー（CBT）[RFC2189]、[RFC2201]、
o Multicast OSPF (MOSPF) [RFC1584].
OマルチキャストOSPF（MOSPF）[RFC1584]。
For the most part, these protocols have fallen into disuse. There may be legacy deployments of some of these protocols, which are not affected by this reclassification. See Section 2.1 for more on each protocol.
ほとんどの部分については、これらのプロトコルは廃止に陥っています。この再分類による影響はありませんこれらのプロトコルのいくつかのレガシー展開があるかもしれません。各プロトコルの詳細については、セクション2.1を参照してください。
Further historical perspective may be found in, for example, [RFC1458], [IMRP-ISSUES], and [IM-GAPS].
さらに歴史的観点は、[RFC1458]、[IMRP-ISSUES]、および[IM-GAPS]、例えば、に見出すことができます。
ASM Any Source Multicast BGMP Border Gateway Multicast Protocol BSR Bootstrap Router CBT Core Based Trees CGMP Cisco Group Management Protocol DR Designated Router DVMRP Distance Vector Multicast Routing Protocol GARP (IEEE 802.1D-2004) Generic Attribute Registration Protocol GMRP GARP Multicast Registration Protocol IGMP Internet Group Management Protocol MBGP Multiprotocol BGP (*not* "Multicast BGP") MLD Multicast Listener Discovery MRP (IEEE 802.1ak) Multiple Registration Protocol MMRP (IEEE 802.1ak) Multicast Multiple Registration Protocol MOSPF Multicast OSPF MSDP Multicast Source Discovery Protocol PGM Pragmatic General Multicast PIM Protocol Independent Multicast PIM-DM PIM - Dense Mode PIM-SM PIM - Sparse Mode PIM-SSM PIM - Source-Specific Multicast RGMP (Cisco's) Router Group Management Protocol RP Rendezvous Point RPF Reverse Path Forwarding SAFI Subsequent Address Family Identifier SDP Session Description Protocol SSM Source-Specific Multicast
ASMどれソースマルチキャストBGMPボーダーゲートウェイマルチキャストプロトコルBSRブートストラップルーターCBTコアベース木CGMPシスコグループ管理プロトコルDR指定ルータDVMRP距離ベクトルマルチキャストルーティングプロトコルGARP（IEEE 802.1D-2004）一般的な属性登録プロトコルGMRP GARPマルチキャスト登録プロトコルIGMPインターネットグループ管理プロトコルMBGPマルチプロトコルBGP（*ない*「マルチキャストBGP」）MLDのマルチキャストリスナ発見MRP（IEEE 802.1ak）複数登録プロトコルMMRP（IEEE 802.1ak）マルチキャスト複数の登録プロトコルMOSPFマルチキャストOSPF MSDPマルチキャストソース発見プロトコルPGM実用的な一般的なマルチキャストPIMプロトコル独立マルチキャストPIM-DMのPIM - 稠密モードPIM-SM、PIM - 希薄モードPIM-SSM PIM - ソース固有のマルチキャストRGMP（Ciscoの）ルータグループ管理プロトコルRPランデブーポイントRPFリバースパス転送SAFI次のアドレスファミリ識別子SDPセッション記述プロトコルSSMソース固有のマルチキャスト
In order to give a simplified summary how each of these class of mechanisms fits together, consider the following multicast receiver scenario.
メカニズムのこれらのクラスのそれぞれが一緒にどのように適合するか簡単な概要を与えるためには、次のマルチキャストレシーバのシナリオを検討してください。
Certain protocols and configurations need to be in place before multicast routing can work. Specifically, when ASM is employed, a router will need to know its RP address(es) (Section 2.4, Section 2.5). With IPv4, RPs need to be connected to other RPs using MSDP so information about sources connected to other RPs can be distributed (Section 2.3). Further, routers need to know if or how multicast topology differs from unicast topology, and routing protocol extensions can provide that information (Section 2.2).
特定のプロトコルおよび構成は、マルチキャストルーティングが動作することができます前に、場所にする必要があります。具体的には、ASMが使用される場合、ルータはRPのアドレス（複数可）（2.4節、2.5節を）知っている必要があります。 IPv4では、RPはMSDPを使用して、他のRPに接続する必要があるので、他のRPに接続されたソースに関する情報（セクション2.3）を分散させることができます。さらに、ルータは、ユニキャストトポロジーと異なる場合、またはどのマルチキャストトポロジー知る必要があり、ルーティングプロトコルの拡張は、その情報（セクション2.2）を提供することができます。
When a host wants to receive a transmission, it first needs to find out the multicast group address (and with SSM, source address) using various means (e.g., SDP description file [RFC4566] or manually). Then it will signal its interest to its first-hop router using IGMP (IPv4) or MLD (IPv6) (Section 2.6). The router initiates setting up hop-by-hop multicast forwarding state (Section 2.1) to the source (in SSM) or first through the RP (in ASM). Routers use an RP to find out all the sources for a group (Section 2.3). When multicast transmission arrives at the receiver's LAN, it is flooded to every Ethernet switch port unless flooding reduction such as IGMP snooping is employed (Section 2.7).
ホストが送信を受信したい場合は、最初のマルチキャストグループアドレスを知る必要がある（およびSSM、送信元アドレスを持つ）は、種々の手段（例えば、手動で、SDP記述ファイル[RFC4566]か）を使用します。それはIGMP（IPv4の）またはMLD（IPv6）の（セクション2.6）を用いて、その最初のホップルータへの関心をシグナリングします。ルータは（SSM）、または最初の（ASM）でRPを介してソースにホップバイホップマルチキャスト転送状態（セクション2.1）の設定を開始します。ルータはグループ（セクション2.3）のためのすべてのソースを見つけるためにRPを使用しています。マルチキャスト送信は、受信機のLANに到着すると、このようなIGMPスヌーピングなど洪水の減少は（2.7節）に採用されていない限り、それは、すべてのイーサネットスイッチポートにフラッディングされます。
The most important part of multicast routing is setting up the multicast forwarding state. State maintenance requires periodic messaging because forwarding state has a timeout. This section describes the protocols commonly used for this purpose.
マルチキャストルーティングの最も重要な部分は、マルチキャスト転送状態を設定しています。転送状態がタイムアウトを持っているので、状態の維持は、定期的なメッセージングが必要です。このセクションでは、一般的に、この目的のために使用されるプロトコルについて説明します。
By far, the most common multicast routing protocol is PIM-SM [RFC4601]. The PIM-SM protocol includes both Any Source Multicast (ASM) and Source-Specific Multicast (SSM) functionality. PIM-SSM is a subset of PIM-SM that does not use the RPs but instead requires that receivers know the (source,group) pair and signal that explicitly. Most current routing platforms support PIM-SM.
はるかに、最も一般的なマルチキャストルーティングプロトコルは、PIM-SM [RFC4601]です。 PIM-SMプロトコルは、任意のソースマルチキャスト（ASM）およびソース固有マルチキャスト（SSM）機能の両方を含みます。 PIM-SSMは、RPを使用しないPIM-SMのサブセットではなく受信機がその明示的に（ソース、グループ）のペアと信号を知っている必要があります。ほとんどの現在のルーティング・プラットフォームは、PIM-SMをサポートしています。
PIM routers elect a designated router on each LAN and the DR is responsible for PIM messaging and source registration on behalf of the hosts. The DR encapsulates multicast packets sourced from the LAN in a unicast tunnel to the RP. PIM-SM builds a unidirectional, group-specific distribution tree consisting of the interested receivers of a group. Initially, the multicast distribution tree is rooted at the RP but later the DRs have the option of optimizing the delivery by building (source,group)-specific trees.
PIMルータは各LAN上の指定ルータを選出し、DRは、ホストの代わりにPIMメッセージングおよびソース登録を担当しています。 DRはRPにユニキャストトンネル内LANから発信マルチキャストパケットをカプセル化します。 PIM-SMは、グループの興味を受信成る一方向、グループ固有の配信ツリーを構築します。最初に、マルチキャスト配信ツリーは、RPをルートとされるが、後のDRは（ソース、グループ）特異的ツリーを構築することにより、配信を最適化するオプションがあります。
A more lengthy introduction to PIM-SM can be found in Section 3 of [RFC4601].
PIM-SMへのより長い導入は、[RFC4601]のセクション3に見出すことができます。
Whereas PIM-SM has been designed to avoid unnecessary flooding of multicast data, PIM-DM [RFC3973] assumed that almost every subnet at a site had at least one receiver for a group. PIM-DM floods multicast transmissions throughout the network ("flood and prune") unless the leaf parts of the network periodically indicate that they are not interested in that particular group.
PIM-SMは、マルチキャストデータの不要なフラッディングを回避するように設計されているのに対し、PIM-DM [RFC3973]は、サイトでほとんどすべてのサブネットは、グループのための少なくとも一つの受信機を持っていたと仮定する。ネットワークの葉の部分は、定期的に、彼らがその特定のグループに興味がないことを示していない限りPIM-DMは、ネットワーク（「洪水とプルーン」）を通じて、マルチキャスト伝送をフラッディングします。
PIM-DM may be an acceptable fit in small and/or simple networks, where setting up an RP would be unnecessary, and possibly in cases where a large percentage of users are expected to want to receive the transmission so that the amount of state the network has to keep is minimal.
PIM-DMは、RPを設定することは不要となり、小さなおよび/または単純なネットワークでは許容フィット、あること、そしておそらくユーザーの大部分は、状態量のように送信を受信したいことが予想される場合にもネットワークは最小限で維持することがあります。
PIM-DM was used as a first step in transitioning away from DVMRP. It also became apparent that most networks would not have receivers for most groups, and to avoid the bandwidth and state overhead, the flooding paradigm was gradually abandoned. Transitioning from PIM-DM to PIM-SM was easy as PIM-SM was designed to use compatible packet formats and dense-mode operation could also be satisfied by a sparse protocol. PIM-DM is no longer in widespread use.
PIM-DMはDVMRPから離れる移行の最初のステップとして使用しました。また、ほとんどのネットワークは、ほとんどのグループのための受信機を持っていないだろう、と、洪水のパラダイムは徐々に放棄された帯域幅と状態のオーバーヘッドを避けるためにことが明らかになりました。 PIM-SMはまた、スパースプロトコルによって満たされる可能性が互換パケットフォーマットと稠密モード動作を使用するように設計されたようにPIM-SMへのPIM-DMからの移行は簡単でした。 PIM-DMは、広範囲に使用されていません。
Many implementations also support so-called "sparse-dense" configuration, where Sparse mode is used by default, but Dense is used for configured multicast group ranges (such as Auto-RP in Section 2.4.3) only. Lately, many networks have transitioned away from sparse-dense to only sparse mode.
多くの実装はまた、唯一のスパースモードがデフォルトで使用されますが、高密度が設定されたマルチキャストグループのために使用されている、いわゆる「疎密」の構成は、（例えば、セクション2.4.3で自動RPとして）の範囲をサポートします。最近、多くのネットワークは、スパースモードに疎密から離れて移行しました。
Bidirectional PIM [RFC5015] is a multicast forwarding protocol that establishes a common shared-path for all sources with a single root. It can be used as an alternative to PIM-SM inside a single domain. It doesn't have data-driven events or data-encapsulation. As it doesn't keep source-specific state, it may be an appealing approach especially in sites with a large number of sources.
双方向PIM [RFC5015]は、単一のルートを持つすべてのソースのための共通の共有パスを確立し、マルチキャスト転送プロトコルです。これは、単一のドメイン内のPIM-SMの代替として使用することができます。これは、データ駆動型のイベントやデータのカプセル化を持っていません。それは、ソース固有の状態を維持していないとして、それは特に発生源の数が多いサイトでは魅力的なアプローチかもしれません。
As of this writing, there is no inter-domain solution to configure a group range to use bidirectional PIM.
この記事の執筆時点では、双方向PIMを使用するグループ範囲を設定するには何のドメイン間の解決策はありません。
Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] [DVMRPv3] [DVMRPv3-AS] was the first protocol designed for multicasting. To get around initial deployment hurdles, it also included tunneling capabilities, which were part of its multicast topology functions.
距離ベクトルマルチキャストルーティングプロトコル（DVMRP）[RFC1075] [DVMRPv3] [DVMRPv3-AS]はマルチキャスティングのために設計された第1のプロトコルでした。初期導入のハードルを回避するために、それはまた、マルチキャストトポロジ機能の一部であったトンネリング機能を、含まれていました。
Currently, DVMRP is used only very rarely in operator networks, having been replaced with PIM-SM. The most typical deployment of DVMRP is at a leaf network, to run from a legacy firewall only supporting DVMRP to the internal network. However, Generic Routing Encapsulation (GRE) tunneling [RFC2784] seems to have overtaken DVMRP in this functionality, and there is relatively little use for DVMRP except in legacy deployments.
現在、DVMRPは、PIM-SMに置き換えられた、オペレータのネットワークに非常にまれにのみ使用されていません。 DVMRPの最も典型的な展開は、内部ネットワークへのDVMRPをサポートする従来のファイアウォールから実行するために、葉のネットワークです。しかし、汎用ルーティングカプセル化（GRE）トンネリング[RFC2784]は、この機能でDVMRPを追い越しているようだ、とレガシー展開を除いてDVMRPのための比較的少ない使用があります。
MOSPF [RFC1584] was implemented by several vendors and has seen some deployment in intra-domain networks. However, since it is based on intra-domain Open Shortest Path First (OSPF) it does not scale to the inter-domain case, operators have found it is easier to deploy a single protocol for use in both intra-domain and inter-domain networks and so it is no longer being actively deployed.
MOSPF [RFC1584]はいくつかのベンダーによって実装されましたし、ドメイン内ネットワークにおけるいくつかの展開を見ています。それはそれは、ドメイン間のケースに拡張しないドメイン内OSPF（Open Shortest Path First）のに基づいているので、オペレータは、ドメイン内およびドメイン間の両方で使用するための単一のプロトコルを展開することが容易である発見しましたそれはもはや積極的に展開されているので、ネットワークや。
BGMP [RFC3913] did not get sufficient support within the service provider community to get adopted and moved forward in the IETF standards process. There were no reported production implementations and no production deployments.
BGMP [RFC3913]は、サービスプロバイダのコミュニティ内で十分な支持を採用し、IETF標準化プロセスに前進取得する取得できませんでした。何の報告生産の実装とNO産生の展開はありませんでした。
CBT [RFC2201][RFC2189] was an academic project that provided the basis for PIM sparse mode shared trees. Once the shared tree functionality was incorporated into PIM implementations, there was no longer a need for a production CBT implementation. Therefore, CBT never saw production deployment.
CBT [RFC2201]、[RFC2189]はPIMスパースモード共有ツリーのための基礎を提供学術プロジェクトでした。共有ツリー機能はPIMの実装に組み込まれた後は、生産CBTの実施の必要性はもはやありませんでした。そのため、CBTは生産の展開を見たことがありません。
It is worth noting that it is possible to run different protocols with different multicast group ranges. For example, treat some groups as dense or bidirectional in an otherwise PIM-SM network; this typically requires manual configuration of the groups or a mechanism like BSR (Section 2.4.3). It is also possible to interact between different protocols; for example, use DVMRP in the leaf network, but PIM-SM upstream. The basics for interactions among different protocols have been outlined in [RFC2715].
異なるマルチキャストグループ範囲で異なるプロトコルを実行することが可能であることは注目に値します。例えば、そうでない場合はPIM-SMネットワーク内の稠密または双方向のようないくつかのグループを扱います。これは、典型的には、手動グループの構成やBSR（セクション2.4.3）のような機構を必要とします。異なるプロトコル間でやり取りすることも可能です。例えば、上流の葉のネットワークでDVMRPが、PIM-SMを使用します。異なるプロトコル間の相互作用のための基本は、[RFC2715]に概説されています。
The following figure gives a concise summary of the deployment status of different protocols as of this writing.
次の図は、この書き込みのように異なるプロトコルの展開ステータスの簡潔な概要を提供します。
+--------------+--------------+----------------+
| Inter-domain | Intra-domain | Status |
+------------+--------------+--------------+----------------+
| PIM-SM | Yes | Yes | Active |
| PIM-DM | Not anymore | Not anymore | Little use |
| BIDIR-PIM | No | Yes | Some uptake |
| DVMRP | Not anymore | Stub only | Going out |
| MOSPF | No | Not anymore | Inactive |
| CBT | No | No | Never deployed |
| BGMP | No | No | Never deployed |
+------------+--------------+--------------+----------------+
From this table, it is clear that PIM-Sparse Mode is the only multicast routing protocol that is deployed inter-domain and, therefore, is most frequently used within multicast domains as well.
この表からは、PIM-スパースモードドメイン間に配備されている唯一のマルチキャストルーティングプロトコルであり、従って、最も頻繁にもマルチキャストドメイン内で使用されていることは明らかです。
PIM has become the de-facto multicast forwarding protocol, but as its name implies, it is independent of the underlying unicast routing protocol. When unicast and multicast topologies are the same ("congruent"), i.e., use the same routing tables (routing information base, RIB), it has been considered sufficient just to distribute one set of reachability information to be used in conjunction with a protocol that sets up multicast forwarding state (e.g., PIM-SM).
PIMは、事実上のマルチキャスト転送プロトコルとなっているが、その名前が示すように、基礎となるユニキャストルーティングプロトコルとは無関係です。ユニキャストおよびマルチキャストトポロジ、すなわち、同一のルーティングテーブル（ルーティング情報ベース、RIB）を使用し、（「一致」）が同じである場合は、プロトコルに関連して使用されるだけで到達可能性情報の一組を配布するために十分であると考えられていますそれは、マルチキャスト転送状態を設定します（例えば、PIM-SM）。
However, when PIM which by default built multicast topology based on the unicast topology gained popularity, it became apparent that it would be necessary to be able to distribute also non-congruent multicast reachability information in the regular unicast protocols. This was previously not an issue, because DVMRP built its own reachability information.
デフォルトでは、ユニキャストトポロジに基づいて、マルチキャストトポロジを構築しましたPIMが人気を得たときしかし、また、通常のユニキャストプロトコルでの非一致マルチキャスト到達可能性情報を配布できるようにすることが必要となることが明らかになりました。 DVMRPは独自の到達可能性情報を築いたので、これは、以前に問題ではありませんでした。
The topology information is needed to perform efficient distribution of multicast transmissions and to prevent transmission loops by applying it to the Reverse Path Forwarding (RPF) check.
トポロジ情報は、マルチキャスト伝送の効率的な配分を実行し、逆方向パス転送（RPF）チェックにそれを適用することにより、送信ループを防ぐために必要です。
This subsection introduces these protocols.
ここでは、これらのプロトコルを紹介します。
Multiprotocol Extensions for BGP-4 [RFC4760] (often referred to as "MBGP"; however, it is worth noting that "MBGP" does *not* stand for "Multicast BGP") specifies a mechanism by which BGP can be used to distribute different reachability information for unicast (SAFI=1) and multicast traffic (SAFI=2). Multiprotocol BGP has been widely deployed for years, and is also needed to route IPv6. Note that SAFI=3 was originally specified for "both unicast and multicast" but has since then been deprecated.
BGP-4のためのマルチプロトコル拡張[RFC4760]（しばしば「MBGP」と呼ばれるが、それは「MBGPは」*「マルチキャストBGP」を表していないことは注目に値する）はBGPを配布するために使用することができるメカニズムを指定ユニキャスト用の異なる到達可能性情報（SAFI = 1）およびマルチキャストトラフィック（SAFI = 2）。マルチプロトコルBGPは広く年間にわたって展開されており、また、ルートのIPv6に必要とされています。サフィ= 3は元々「ユニキャストとマルチキャストの両方」に指定されたが、それ以来、廃止されたことに留意されたいです。
These extensions are in widespread use wherever BGP is used to distribute unicast topology information. Multicast-enabled networks that use BGP should use Multiprotocol BGP to distribute multicast reachability information explicitly even if the topologies are congruent to make an explicit statement about multicast reachability. A number of significant multicast transit providers even require this, by doing the RPF lookups solely based on explicitly advertised multicast address family.
これらの拡張機能は、BGPは、ユニキャストトポロジ情報を配布するために使用されている場所に広く使用されています。トポロジは、マルチキャストの到達可能性に関する明確な声明を作るために一致している場合、BGPも明示的マルチキャスト到達可能性情報を配布するためにマルチプロトコルBGPを使用する必要があります使用してマルチキャスト対応ネットワーク。大きなマルチキャストトランジットプロバイダの数も、単に明示的にアドバタイズされたマルチキャストアドレスファミリに基づいてRPFルックアップを行うことで、これを必要とします。
Similar to BGP, some Interior Gateway Protocols (IGPs) also provide the capability for signalling differing topologies, for example IS-IS multi-topology extensions [M-ISIS]. These can be used for a multicast topology that differs from unicast. Similar but not so widely implemented work exists for OSPF [RFC4915].
BGPと同様、いくつかのインテリアゲートウェイプロトコル（のIGP）はまた、例えばISISマルチトポロジの拡張[M-ISIS]のために、異なるトポロジをシグナリングするための能力を提供します。これらは、ユニキャストとは異なり、マルチキャストトポロジのために使用することができます。似ていますが、それほど広く実装されていない作品は、OSPF [RFC4915]のために存在します。
It is worth noting that inter-domain incongruence and intra-domain incongruence are orthogonal, so one doesn't require the other. Specifically, inter-domain incongruence is quite common, while intra-domain incongruence isn't, so you see much more deployment of MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well without protocols handling intra-domain incongruence. However, the availability of multi-topology mechanisms may in part replace the typically used workarounds such as tunnels.
これは、ドメイン間の不適合とドメイン内の不適合が直交していることは注目に値するので、一方が他方を必要としません。具体的には、ドメイン内の不適合がない間、ドメイン間の不適合は、非常に一般的ですので、あなたは、MT-ISIS / OSPFよりMBGPのはるか展開を参照してください。一般的に展開されたネットワークは、ドメイン内の不適合を扱うプロトコルせずによく管理されています。しかし、マルチトポロジーメカニズムの利用可能性は、部分的にはそのようなトンネルのような一般的に使用される回避策を置き換えることができます。
An interesting case occurs when some routers do not distribute multicast topology information explicitly while others do. In particular, this happens when some multicast sites in the Internet are using plain BGP while some use MBGP.
興味深いケースは、他の人がそうしながら、いくつかのルータが明示的マルチキャストトポロジ情報を配布しない場合に発生します。一部はMBGPを使用しながら、インターネットでいくつかのマルチキャストのサイトは、プレーンBGPを使用しているとき特に、これは起こります。
Different implementations deal with this in different ways. Sometimes, multicast RPF mechanisms first look up the multicast routing table, or M-RIB ("topology database") with a longest prefix match algorithm, and if they find any entry (including a default route), that is used; if no match is found, the unicast routing table is used instead.
異なる実装は異なる方法でこの問題に対処します。時々、マルチキャストRPFメカニズムは、最初のマルチキャストルーティングテーブルをルックアップ、またはM-RIB（「トポロジーデータベース」）、最長プレフィックスマッチアルゴリズムにより、それらが（デフォルトルートを含む）任意のエントリを見つけた場合、それが使用されます。一致が見つからない場合は、ユニキャストルーティングテーブルが代わりに使用されます。
An alternative approach is to use longest prefix match on the union of multicast and unicast routing tables; an implementation technique here is to copy the whole unicast routing table over to the multicast routing table. The important point to remember here, though, is to not override the multicast-only routes; if the longest prefix match would find both a (copied) unicast route and a multicast-only route, the latter should be treated as preferable.
別のアプローチは、マルチキャストおよびユニキャストルーティングテーブルの組合で最長プレフィックスマッチを使用することです。ここで実装技術は、マルチキャストルーティングテーブルの上に全体のユニキャストルーティングテーブルをコピーすることです。ここで覚えておくべき重要な点は、しかし、マルチキャストルートだけを上書きしないことです。最長プレフィックスマッチが（コピー）ユニキャストルートとマルチキャスト専用ルートの両方を見つけるならば、後者が好ましいものとして扱われるべきです。
Another implemented approach is to just look up the information in the unicast routing table, and provide the user capabilities to change that as appropriate, using for example copying functions discussed above.
別の実装のアプローチは、単にユニキャストルーティングテーブル内の情報を検索し、上述の例コピー機能のために使用して、必要に応じてそれを変更するためのユーザ機能を提供することです。
A congruent topology can be deployed using unicast routing protocols that provide no support for a separate multicast topology. In intra-domain that approach is often adequate. However, it is recommended that if inter-domain routing uses BGP, multicast-enabled sites should use MP-BGP SAFI=2 for multicast and SAFI=1 for unicast even if the topology was congruent to explicitly signal "yes, we use multicast".
合同トポロジーは、別個のマルチキャストトポロジのためのサポートを提供しないユニキャストルーティングプロトコルを使用して展開することができます。ドメイン内ではそのアプローチは、多くの場合、十分です。しかし、ドメイン間ルーティングは、BGPを使用している場合、マルチキャスト対応のサイトは、トポロジーが明示的に「はい、私たちはマルチキャストを使う」を知らせるために一致した場合でも、ユニキャスト用マルチキャストおよびSAFI = 1のためにMP-BGP SAFI = 2を使用することをお勧めします。
The following table summarizes the approaches that can be used to distribute multicast topology information.
次の表は、マルチキャストトポロジ情報を配布するために使用することができますアプローチをまとめたもの。
+----------------+--------------+
| Inter-domain | Intra-domain |
+--------------------- +----------------+--------------+
| MP-BGP SAFI=2 | Yes | Yes |
| MP-BGP SAFI=3 | Doesn't work | Doesn't work |
| IS-IS multi-topology | Not applicable | Yes |
| OSPF multi-topology | Not applicable | Few implem. |
+----------------------+----------------+--------------+
"Not applicable" refers to the fact that IGP protocols can't be used in inter-domain routing. "Doesn't work" means that while MP-BGP SAFI=3 was defined and could apply, that part of the specification has not been implemented and can't be used in practice. "Yes" lists the mechanisms which are generally applicable and known to work. "Few implem." means that the approach could work but is not commonly available.
「該当なし」IGPプロトコルは、ドメイン間のルーティングに使用することができないという事実を指します。 「動かない」MP-BGPサフィ= 3を定義し、適用することができるが、仕様の一部が実装されておらず、実際に使用することができないことを意味します。 「はい」を一般的に適用して動作することが知られているメカニズムを示しています。 "少数implem。"アプローチは、仕事ができることを意味しますが、一般的には使用できません。
To build a multicast distribution tree, the routing protocol needs to find out where the sources for the group are. In case of SSM, the user specifies the source IP address or it is otherwise learned out of band.
マルチキャスト配信ツリーを構築するには、ルーティングプロトコルは、グループのための情報源がどこにあるかを知る必要があります。 SSMの場合、ユーザは送信元IPアドレスを指定するか、そうでない場合は、バンドの外に学習します。
In ASM, the RPs know about all the active sources in a local PIM domain. As a result, when PIM-SM or BIDIR-PIM is used in intra-domain the sources are learned as a feature of the protocol itself.
ASMでは、RPはローカルPIMドメイン内のすべてのアクティブなソースを知っています。 PIM-SMまたはBIDIR-PIMは、ドメイン内で使用される場合、結果として、光源は、プロトコル自体の特徴として学習されています。
Having a single PIM-SM domain for the whole Internet is an insufficient model for many reasons, including scalability, administrative boundaries, and different technical tradeoffs. Therefore, it is required to be able to split up the multicast routing infrastructures to smaller domains, and there must be a way to share information about active sources using some mechanism if the ASM model is to be supported.
インターネット全体のための単一のPIM-SMドメインを持つことは、スケーラビリティ、管理境界、および異なる技術的なトレードオフを含め、多くの理由のために不十分なモデルです。したがって、より小さなドメインにマルチキャストルーティングインフラストラクチャを分割することができるように要求され、そしてASMモデルがサポートされる場合、いくつかのメカニズムを使用して、アクティブソースに関する情報を共有する方法がなければなりません。
This section discusses the options of learning active sources that apply in an inter-domain environment.
このセクションでは、ドメイン間の環境に適用するアクティブなソースを学習のオプションについて説明します。
Source-specific Multicast [RFC4607] (sometimes also referred to as "single-source Multicast") does not count on learning active sources in the network. Recipients need to know the source IP addresses using an out of band mechanism which are used to subscribe to the (source, group) channel. The multicast routing uses the source address to set up the state and no further source discovery is needed.
ソース固有のマルチキャスト[RFC4607]（時には「シングルソースのマルチキャスト」と呼ばれる）は、ネットワーク内のアクティブなソースを学ぶ上でカウントされません。受信者は、（ソース、グループ）チャネルにサブスクライブするために使用されたバンド機構のアウトを使用してソースIPアドレスを知る必要があります。マルチキャストルーティングは状態を設定するために、送信元アドレスを使用して、それ以上のソースの発見は必要ありません。
As of this writing, there are attempts to analyze and/or define out-of-band source discovery functions which would help SSM in particular [DYNSSM-REQ].
これを書いているように、分析及び/又は特定[DYNSSM-REQ]でSSMに役立つアウト・オブ・バンドソース発見関数を定義しようとする試みがあります。
Multicast Source Discovery Protocol [RFC3618] was invented as a stop-gap mechanism, when it became apparent that multiple PIM-SM domains (and RPs) were needed in the network, and information about the active sources needed to be propagated between the PIM-SM domains using some other protocol.
マルチキャストソース発見プロトコル[RFC3618]は、複数のPIM-SMドメイン（とのRP）は、ネットワーク内で必要であったことが明らかになったとき、ストップギャップ機構として考案、およびPIM-間で伝播する必要がアクティブソースに関する情報れましたSMは、いくつかの他のプロトコルを使用してドメイン。
MSDP is also used to share the state about sources between multiple RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The same can be achieved using PIM extensions [RFC4610]. See Section 2.5 for more information.
MSDPはまたための単一のドメイン、例えば、冗長性の目的で[RFC3446]で複数のRPとの間のソースに関する状態を共有するために使用されます。同じことは、PIM拡張[RFC4610]を使用して達成することができます。詳細については、セクション2.5を参照してください。
There is no intent to define MSDP for IPv6, but instead use only SSM and Embedded-RP [MCAST-ISSUES].
唯一のSSMおよびEmbedded-RP [MCAST-問題] IPv6のMSDPを定義し、代わりに使用する意図はありません。
Embedded-RP [RFC3956] is an IPv6-only technique to map the address of the RP to the multicast group address. Using this method, it is possible to avoid the use of MSDP while still allowing multiple multicast domains (in the traditional sense).
埋め込み-RPの[用RFC3956]マルチキャストグループアドレスにRPのアドレスをマッピングするIPv6のみの技術です。この方法を使用して、まだ（伝統的な意味で）複数のマルチキャストドメインを可能にしながら、MSDPの使用を回避することが可能です。
The model works by defining a single RP address for a particular group for all of the Internet, so there is no need to share state about that with any other RPs. If necessary, RP redundancy can still be achieved with Anycast-RP using PIM [RFC4610].
モデルは、インターネットのすべてのための特定のグループのための単一のRPアドレスを定義することによって動作しますので、他のRPを持つことについての状態を共有する必要はありません。必要に応じて、RPの冗長性は依然としてPIM [RFC4610]を使用して、エニーキャスト-RPを用いて達成することができます。
The following table summarizes the source discovery approaches and their status.
次の表は、ソースの発見手法とそのステータスをまとめたもの。
+------+------+------------------------------+
| IPv4 | IPv6 | Status |
+----------------------+------+------+------------------------------+
| Bidir single domain | Yes | Yes | OK but for intra-domain only |
| PIM-SM single domain | Yes | Yes | OK |
| PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM |
| PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option |
| SSM | Yes | Yes | No major uptake yet |
+----------------------+------+------+------------------------------+
PIM-SM and BIDIR-PIM configuration mechanisms exist, which are used to configure the RP addresses and the groups that are to use those RPs in the routers. This section outlines the approaches.
PIM-SMおよびBIDIR-PIMコンフィギュレーションメカニズムがRPアドレスとルータでそれらのRPを使用するようにしているグループを構成するために使用され、存在します。このセクションでは、アプローチの概要を説明します。
It is often easiest just to manually configure the RP information on the routers when PIM-SM is used.
これは、PIM-SMを使用するときだけ手動でルータのRP情報を設定するには、多くの場合、最も簡単です。
Originally, static RP mapping was considered suboptimal since it required explicit configuration changes every time the RP address changed. However, with the advent of anycast RP addressing, the RP address is unlikely to ever change. Therefore, the administrative burden is generally limited to initial configuration. Since there is usually a fair amount of multicast configuration required on all routers anyway (e.g., PIM on all interfaces), adding the RP address statically isn't really an issue. Further, static anycast RP mapping provides the benefits of RP load sharing and redundancy (see Section 2.5) without the complexity found in dynamic mechanisms like Auto-RP and Bootstrap Router (BSR).
それが明示的な設定は、RPアドレスが変更されるたびに変更に必要なので、本来は、静的RPマッピングは、次善と考えられました。しかし、エニーキャストRPの出現アドレッシングと、RPアドレスは、これまでに変更することはほとんどありません。そのため、管理者の負担は、一般的に初期構成に限定されています。とにかくすべてのルータで必要なマルチキャスト設定のかなりの量が通常があるので（例えば、すべてのインターフェイス上でPIM）は、静的RPアドレスを追加することは本当に問題ではありません。さらに、静的エニーキャストRPマッピングがRPの負荷分散と冗長性の利点を提供する自動RPおよびブートストラップルータ（BSR）のような動的なメカニズムで見出さ複雑させずに（セクション2.5を参照）。
With such design, an anycast RP uses an address that is configured on a loopback interface of the routers currently acting as RPs, and state is distributed using PIM [RFC4610] or MSDP [RFC3446].
このような設計では、エニーキャストRPは、現在のRPとして動作するルータのループバックインターフェイスに設定されたアドレスを使用し、状態はPIM [RFC4610]またはMSDP [RFC3446]を使用して分配されます。
Using this technique, each router might only need to be configured with one, portable RP address.
この技術を使用して、各ルータは、唯一の、ポータブルRPアドレスで設定する必要がある場合があります。
Embedded-RP provides the information about the RP's address in the group addresses that are delegated to those who use the RP, so unless no other ASM than Embedded-RP is used, the network administrator only needs to configure the RP routers.
組み込み-RP組み込み-RPよりも、他のASMが使用されていない場合を除き、ネットワーク管理者のみがRPルータを設定する必要があるので、RPを使用する人に委任されているグループアドレスでRPのアドレスに関する情報を提供します。
While Embedded-RP in many cases is sufficient for IPv6, other methods of RP configuration are needed if one needs to provide ASM service for other than Embedded-RP group addresses. In particular, service discovery type of applications may need hard-coded addresses that are not dependent on local RP addresses.
多くの場合、組み込み-RPは、IPv6のための十分であるが、一方が他方よりも組み込み-RPのグループアドレスのためのASMサービスを提供する必要がある場合、RP構成の他の方法が必要とされています。具体的には、アプリケーションのサービス発見のタイプは、ローカルRPアドレスに依存しないハードコーディングされたアドレスが必要な場合があります。
As the RP's address is exposed to the users and applications, it is very important to ensure it does not change often, e.g., by using manual configuration of an anycast address.
RPのアドレスは、ユーザやアプリケーションにさらされているとして、エニーキャストアドレスの手動設定を使用することにより、例えば、頻繁に変更されないことを確認することが非常に重要です。
BSR [RFC5059] is a mechanism for configuring the RP address for groups. It may no longer be in as wide use with IPv4 as it was earlier, and for IPv6, Embedded-RP will in many cases be sufficient.
BSR [RFC5059]はグループのためのRPアドレスを設定するためのメカニズムです。それは以前にあったようにそれはもはや、IPv4の場合と同様に広く使用されないかもしれない、とIPv6のために、組み込み-RPは、多くの場合、十分であろう。
Cisco's Auto-RP is an older, proprietary method for distributing group to RP mappings, similar to BSR. Auto-RP has little use today.
シスコの自動RPがBSRに似RPマッピングにグループを配布する古い、独自の方法です。自動RPは、今日はほとんど使用されています。
Both Auto-RP and BSR require some form of control at the routers to ensure that only valid routers are able to advertise themselves as RPs. Further, flooding of BSR and Auto-RP messages must be prevented at PIM borders. Additionally, routers require monitoring that they are actually using the RP(s) the administrators think they should be using, for example, if a router (maybe in customer's control) is advertising itself inappropriately. All in all, while BSR and Auto-RP provide easy configuration, they also provide very significant configuration and management complexity.
自動RPおよびBSRの両方が唯一の有効なルータがRPとして自分自身を宣伝することができることを保証するために、ルータでコントロールのいくつかのフォームを必要としています。さらに、BSRとAuto-RPメッセージの氾濫は、PIM境界で防止しなければなりません。また、ルータは、彼らが実際に（多分、顧客のコントロールに）ルータが不適切に自分自身をアドバタイズしている場合、管理者は、彼らは例えば、使用されるべきだと思う（S）RPを使用していることを監視が必要です。 BSRとAuto-RPは、簡単な設定を提供しながら、すべてのすべてで、彼らはまた、非常に重要な構成および管理の複雑さを提供します。
It is worth noting that both Auto-RP and BSR were deployed before the use of a manually configured anycast-RP address became relatively commonplace, and there is actually relatively little need for them today unless there is a need to configure different properties (e.g., sparse, dense, bidirectional) in a dynamic fashion.
これは、手動で構成エニーキャスト-RPアドレスの使用は比較的ありふれなる前に自動RPおよびBSRの両方が展開されたことは注目に値する、と別のプロパティを設定する必要がある場合を除き、それらのために、実際には比較的少ない必要性は、今日がある（例えば、動的な方法で）、疎密、双方向。
The following table summarizes the RP discovery mechanisms and their status. With the exception of Embedded-RP, each mechanism operates within a PIM domain.
次の表は、RPディスカバリメカニズムとそのステータスをまとめたもの。組込み-RPを除いて、各機構は、PIMドメイン内で動作します。
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Static RP | Yes | Yes | Especially in ISPs |
| Auto-RP | Yes | No | Legacy deployment |
| BSR | Yes | Yes | Some, anycast simpler |
| Embedded-RP | No | Yes | Growing |
+--------------------+------+------+-----------------------+
Having only one RP in a PIM-SM domain would be a single point of failure for the whole multicast domain. As a result, a number of mechanisms have been developed to either eliminate the RP functionality or to enhance RPs' redundancy, resilience against failures, and to recover from failures quickly. This section summarizes these techniques explicitly.
PIM-SMドメインに一つだけのRPを持つことは、全体のマルチキャストドメインのための単一障害点になります。その結果、機構の数は、RPの機能を排除するかまたは障害に対してのRP冗長性、回復力を強化するために、かつ迅速に障害から回復するために開発されています。このセクションでは、明示的にこれらの技術をまとめました。
As mentioned in Section 2.3.2, MSDP is also used to share the state about sources between multiple RPs in a single domain, e.g., for redundancy purposes [RFC3446]. The purpose of MSDP in this context is to share the same state information on multiple RPs for the same groups to enhance the robustness of the service.
セクション2.3.2で述べたように、MSDPはまた、冗長性の目的で[RFC3446]のために、例えば、単一ドメイン内の複数のRPとの間のソースに関する状態を共有するために使用されます。この文脈でのMSDPの目的は、サービスの堅牢性を強化するために、同じグループのために複数のRPで同じ状態情報を共有することです。
Recent PIM extensions [RFC4610] also provide this functionality. In contrast to MSDP, this approach works for both IPv4 and IPv6.
最近のPIM拡張[RFC4610]もこの機能を提供します。 MSDPとは対照的に、このアプローチは、IPv4とIPv6の両方のために動作します。
While Anycast RP shares state between RPs so that RP failure causes only small disturbance, stateless approaches are also possible with a more limited resiliency. A traditional mechanism has been to use Auto-RP or BSR (see Section 2.4.3) to select another RP when the active one failed. However, the same functionality could be achieved using a shared-unicast RP address ("anycast RP without state sharing") without the complexity of a dynamic mechanism. Further, Anycast RP offers a significantly more extensive failure mitigation strategy, so today there is actually very little need to use stateless failover mechanisms, especially dynamic ones, for redundancy purposes.
RP間しばらくエニーキャストRPの共有状態RP障害がわずかな乱れが発生するように、ステートレスなアプローチは、より限定された弾力性でも可能です。伝統的なメカニズムは、アクティブな1が失敗したときに、別のRPを選択する（2.4.3を参照）、自動RPまたはBSRを使用することでした。しかし、同じ機能が動的機構の複雑化することなく、共有ユニキャストRPアドレス（「状態を共有することなくエニーキャストRP」）を使用して達成することができます。さらに、エニーキャストRPは、冗長性のために、ステートレスフェールオーバーメカニズム、特にダイナミックなものを、使用することはほとんど必要性が実際に存在しているので、今日、かなり多くの大規模な障害軽減戦略を提供しています。
Because bidirectional PIM (see Section 2.1.3) does not switch to shortest path tree (SPT), the final multicast tree may be established faster. On the other hand, PIM-SM or SSM may converge more quickly especially in scenarios (e.g., unicast routing change) where bidirectional needs to re-do the Designated Forwarder election.
双方向PIM（セクション2.1.3を参照）を最短経路ツリー（SPT）に切り替えていないため、最終的なマルチキャストツリーが速く確立することができます。一方、PIM-SMまたはSSMは特にシナリオでより迅速に収束することができる（例えば、ユニキャストルーティング変化）双方向の指定フォワーダ選挙を再度行う必要があります。
The following table summarizes the techniques for enhanced redundancy.
次の表は、強化され、冗長性のための技術をまとめました。
+------+------+-----------------------+
| IPv4 | IPv6 | Deployment |
+--------------------+------+------+-----------------------+
| Anycast RP w/ MSDP | Yes | No | De-facto approach |
| Anycast RP w/ PIM | Yes | Yes | Newer approach |
| Stateless RP fail. | Yes | Yes | Causes disturbance |
| BIDIR-PIM | Yes | Yes | Deployed at some sites|
+--------------------+------+------------------------------+
Previous sections have dealt with the components required by routers to be able to do multicast routing. Obviously, the real users of multicast are the hosts: either sending or receiving multicast. This section describes the required interactions with hosts.
前のセクションでは、マルチキャストルーティングを行うことができるようにルーターが必要なコンポーネントを扱っています。明らかに、マルチキャストの実際のユーザーは、ホストである：マルチキャストを送信または受信のどちらか。このセクションでは、ホストとの必要な相互作用を説明します。
After choosing a multicast group through a variety of means, hosts just send the packets to the link-layer multicast address, and the designated router will receive all the multicast packets and start forwarding them as appropriate. A host does not need to be a member of the group in order to send to it [RFC1112].
様々な手段を通じてマルチキャストグループを選択した後、ホストは単なるリンク層マルチキャストアドレスにパケットを送信し、指定されたルータは、すべてのマルチキャストパケットを受信し、適切にそれらの転送を開始します。ホストは、[RFC1112]に送信するために、グループのメンバーである必要はありません。
In intra-domain or Embedded-RP scenarios, ASM senders may move to a new IP address without significant impact on the delivery of their transmission. SSM senders cannot change the IP address unless receivers join the new channel or the sender uses an IP mobility technique that is transparent to the receivers.
ドメイン内または内蔵-RPのシナリオでは、ASMの送信者は、それらの送信の配信に大きな影響を与えることなく、新しいIPアドレスに移動してもよいです。受信機は新しいチャネルに参加したり、送信者が受信機に透明なIPモビリティ技術を使用しない限り、SSMの送信者は、IPアドレスを変更することはできません。
Hosts signal their interest in receiving a multicast group or channel by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are still commonplace, but are also often used in new deployments. Some vendors also support SSM mapping techniques for receivers which use an older IGMP/MLD version where the router maps the join request to an SSM channel based on various, usually complex means of configuration.
ホストはIGMP [RFC3376]とMLD [RFC3810]を使用することによって、マルチキャストグループまたはチャネルを受信することに関心を知らせます。 IGMPv2のとのMLDv1はまだ一般的であるが、また、多くの場合、新しい展開で使用されています。一部のベンダーは、ルータは、コンフィギュレーションの様々な、通常は複雑な手段に基づいて、SSMチャネルへの参加要求をマップする古いIGMP / MLDのバージョンを使用する受信機のためSSMマッピング技術をサポートしています。
The following table summarizes the techniques host interaction.
次の表は、技術のホストの相互作用をまとめました。
+-------+------+----------------------------+
| IPv4 | IPv6 | Notes |
+--------------------+-------+------+----------------------------+
| Host sending | Yes | Yes | No support needed |
| Host receiving ASM | IGMP | MLD | Any IGMP/MLD version |
| Host receiving SSM | IGMPv3| MLDv2| Any version w/ SSM-mapping |
+--------------------+-------+------+----------------------------+
Multicast transmission in the link layer, for example Ethernet, typically includes some form of flooding the packets through a LAN. This causes unnecessary bandwidth usage and discarding unwanted frames on those nodes which did not want to receive the multicast transmission.
リンク層におけるマルチキャスト送信は、例えばイーサネット（登録商標）のために、典型的にはLANを介してパケットをフラッディングのいくつかのフォームを含みます。これにより、不要な帯域幅の使用を原因とし、マルチキャスト送信を受信したくなかったそれらのノード上の不要なフレームを廃棄します。
Therefore a number of techniques have been developed, to be used in Ethernet switches between routers, or between routers and hosts, to limit the flooding.
したがって、多くの技術が、開発されているルータとの間のイーサネット・スイッチに使用される、またはルータとホストとの間で、フラッディングを制限すること。
Some mechanisms operate with IP addresses, others with MAC addresses. If filtering is done based on MAC addresses, hosts may receive unnecessary multicast traffic (filtered out in the hosts' IP layer) if more than one IP multicast group addresses maps into the same MAC address, or if IGMPv3/MLDv2 source filters are used. Filtering based on IP destination addresses, or destination and sources addresses, will help avoid these but requires parsing of the Ethernet frame payload.
いくつかのメカニズムは、IPアドレス、MACアドレスを持つ他の人と動作します。フィルタリングは、MACアドレスに基づいて行われている場合、複数のIPマルチキャストグループが同じMACアドレスにマップをアドレス場合、またはのIGMPv3 / MLDv2のソース・フィルタが使用される場合、ホストは（ホストのIP層に除外）、不要なマルチキャストトラフィックを受信することができます。フィルタリングは、IP宛先アドレス、または宛先とソースアドレスに基づいて、これらを回避するのに役立ちますが、イーサネットフレームのペイロードの解析を必要とします。
These options are discussed in this section.
これらのオプションは、このセクションで説明されています。
A proprietary solution, Cisco's RGMP [RFC3488] has been developed to reduce the amount of flooding between routers in a switched networks. This is typically only considered a problem in some Ethernet-based Internet Exchange points or VPNs.
独自のソリューション、シスコのRGMP [RFC3488]はスイッチドネットワーク内のルータ間の洪水の量を減少させるために開発されました。これは一般的にのみ、いくつかのイーサネットベースのインターネットエクスチェンジやVPNの問題と考えられています。
There have been proposals to observe and possibly react ("snoop") PIM messages [PIM-SNOOP].
提案は観察し、おそらく反応することがありました（「スヌープ」）PIMメッセージ[PIM-SNOOP]。
There are a number of techniques to help reduce flooding both from a router to hosts, and from a host to the routers (and other hosts).
両方のルータからホストにあふれ削減、およびルータ（および他のホスト）へのホストから支援するための技術がいくつかあります。
Cisco's proprietary CGMP [CGMP] provides a solution where the routers notify the switches, but also allows the switches to snoop IGMP packets to enable faster notification of hosts no longer wishing to receive a group. Implementations of CGMP do not support fast leave behaviour with IGMPv3. Due to IGMP report suppression in IGMPv1 and IGMPv2, multicast is still flooded to ports which were once members of a group as long as there is at least one receiver on the link. Flooding restrictions are done based on multicast MAC addresses. Implementations of CGMP do not support IPv6.
シスコ独自のCGMP [CGMP]はルータがスイッチに通知するソリューションを提供するだけでなく、スイッチはもはやグループを受信することを望むホストの高速通知を可能にするために、IGMPパケットをスヌープすることを可能にします。 CGMPの実装はIGMPv3の持つ高速脱退の動作をサポートしていません。 IGMPv1およびIGMPv2のにIGMPレポート抑制のために、マルチキャストは依然として限りリンク上の少なくとも一つの受信機があるので、一度グループのメンバーであったポートにフラッディングされます。洪水の制限は、マルチキャストMACアドレスに基づいて行われます。 CGMPの実装はIPv6をサポートしていません。
IEEE 802.1D-2004 specification describes Generic Attribute Registration Protocol (GARP), and GARP Multicast Registration Protocol (GMRP) [GMRP] is a link-layer multicast group application of GARP that notifies switches about MAC multicast group memberships. If GMRP is used in conjunction with IP multicast, then the GMRP registration function would become associated with an IGMP "join". However, this GMRP-IGMP association is beyond the scope of GMRP. GMRP requires support at the host stack and it has not been widely implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete being replaced by Multiple Registration Protocol (MRP) and Multicast Multiple Registration Protocol (MMRP) that are being specified in IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between bridges. Some further information about GARP/GMRP is also available in Appendix B of [RFC3488].
IEEE 802.1D-2004の仕様は一般属性登録プロトコル（GARP）を記述し、GARPマルチキャスト登録プロトコル（GMRP）GMRP] MACマルチキャストグループメンバーシップに関するスイッチを通知GARPのリンク層マルチキャストグループのアプリケーションがあります。 GMRPは、IPマルチキャストと組み合わせて使用されている場合は、GMRP登録機能は、IGMP「参加」に関連付けられてなります。しかし、このGMRP-IGMP協会は、GMRPの範囲を超えています。 GMRPは、ホストスタックのサポートを必要とし、それが広く実装されていません。さらに、IEEE 802.1は、GARPと廃止GMRPは、複数の登録プロトコル（MRP）および[802.1ak] IEEE 802.1akで指定されているマルチキャスト複数の登録プロトコル（MMRP）によって置換されているとみなし。 MMRPは、主ブリッジとの間で使用されることが期待されます。 GARP / GMRPに関するいくつかの詳細は、[RFC3488]の付録Bにも使用可能です。
IGMP snooping [RFC4541] appears to be the most widely implemented technique. IGMP snooping requires that the switches implement a significant amount of IP-level packet inspection; this appears to be something that is difficult to get right, and often the upgrades are also a challenge. Snooping support is commonplace for IGMPv1 and IGMPv2, but fewer switches support IGMPv3 or MLD (any version) snooping. In the worst case, enabling IGMP snooping on a switch that does not support IGMPv3 snooping breaks multicast capabilities of nodes using IGMPv3.
IGMPスヌーピング[RFC4541]は、最も広く実装技術であることが表示されます。 IGMPスヌーピングは、スイッチはIPレベルのパケット検査を大量に実装する必要があります。これは、権利を取得することは困難である何かであるように表示され、多くの場合、アップグレードも挑戦しています。サポートをスヌーピングすることはIGMPv1およびIGMPv2のために一般的であるが、少数のスイッチは、IGMPv3のかMLD（任意のバージョン）スヌーピングをサポートしています。最悪の場合には、IGMPv3のスヌーピング休憩にIGMPv3のを使用してノードのマルチキャスト機能をサポートしていないスイッチ上でIGMPスヌーピングを有効にします。
Snooping switches also need to identify the ports where routers reside and therefore where to flood the packets. This can be accomplished using Multicast Router Discovery protocol [RFC4286], looking at certain IGMP queries [RFC4541], looking at PIM Hello and possibly other messages, or by manual configuration. An issue with
スヌーピングスイッチはまた、ルータが存在し、したがって、パケットをフラッディングするポートを特定する必要があります。これは、PIMハローおよびおそらく他のメッセージを見て、または手動設定によって、[RFC4541]特定のIGMPクエリを見て、[RFC4286]マルチキャストルータ発見プロトコルを使用して達成することができます。問題と
PIM snooping at LANs is that PIM messages can't be turned off or encrypted, leading to security issues [PIM-THREATS].
LANでPIMスヌーピングは、PIMメッセージがオフになっているか、暗号化、セキュリティの問題[PIM-脅威]につながることができないということです。
IGMP proxying [RFC4605] is sometimes used either as a replacement of a multicast routing protocol on a small router, or to aggregate IGMP/ MLD reports when used with IGMP snooping.
IGMPプロキシは[RFC4605]は時々どちらか小さいルータにマルチキャストルーティングプロトコルの代替として使用され、またはIGMPスヌーピングと共に使用した場合、IGMP / MLDレポートを集約します。
The following table summarizes the techniques for multicast flooding reduction inside a single link for router-to-router and last-hop LANs.
次の表は、ルーターと最後のホップLANのための単一のリンク内のマルチキャストフラッディングの低減のための技術をまとめました。
+--------+-----+----------------------------+
| R-to-R | LAN | Notes |
+-----------------------+--------+-----+----------------------------+
| Cisco's RGMP | Yes | No | Replaced by PIM snooping |
| PIM snooping | Yes | No | Security issues in LANs |
| IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD rare |
| Multicast Router Disc | No | Yes | Few if any implem. yet |
| IEEE GMRP and MMRP | No | No | No host/router deployment |
| Cisco's CGMP | No | Yes | Replaced by other snooping |
+-----------------------+--------+-----+----------------------------+
Tutoring a couple multicast-related papers, the latest by Kaarle Ritvanen [RITVANEN] convinced the author that up-to-date multicast routing and address assignment/allocation documentation is necessary.
カップルのマルチキャスト関連の論文を指導、KAARLE Ritvanen [RITVANEN]による、最新のは、最新のマルチキャストルーティングおよびアドレスの割り当て/割り当てのドキュメントが必要である著者を確信させました。
Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon Chisholm, John Zwiebel, Dan Romascanu, Thomas Morin, Ron Bonica, Prashant Jhingran, and Tim Polk provided good comments, helping in improving this document.
レオナルドジュリアーノ、ジェームズ・リンガード、ジャン・ジャック・Pansiot、デイブ・マイヤー、スティグVenaas、トムPusateri、マーシャルユーバンクス、ディノファリナッチ、バーラト・ジョシ、アルバート・マンフレディ、ジャン・ジャック・Pansiot、スペンサードーキンスシャロンチザム、ジョンZwiebel、ダンRomascanu、トーマスモリン、ロンBonica、のPrashant Jhingran、およびティムポークは、このドキュメントの改善に貢献し、良いコメントを提供しました。
IANA has updated the following registries by adding a reference to this document:
IANAはこのドキュメントへの参照を追加することにより、以下のレジストリを更新しました：
o OSPFv2 Options Registry: MC-bit
OSPFv2のオプションレジストリO：MC-ビット
o OSPFv2 Link State (LS) Type: Group-membership-LSA
OのOSPFv2リンクステート（LS）タイプ：グループ・メンバーシップLSA
o OSPFv2 Router Properties Registry: W-bit o OSPFv3 Options Registry: MC-bit
OのOSPFv2ルータのプロパティレジストリ：MC-ビット：OSPFv3のオプションレジストリO Wビット
o OSPFv3 LSA Function Code Registry: Group-membership-LSA
OのOSPFv3 LSA機能コードレジストリ：グループ・メンバーシップLSA
o OSPFv3 Prefix Options Registry: MC-bit
OSPFv3のプレフィックスオプションレジストリO：MC-ビット
This memo only describes different approaches to multicast routing, and this has no security considerations; the security analysis of the mentioned protocols is out of scope of this memo.
このメモは、マルチキャストルーティングに異なるアプローチを説明し、これにはセキュリティ上の配慮を持っていません。前述のプロトコルのセキュリティ分析は、このメモの範囲外です。
However, there has been analysis of the security of multicast routing infrastructures [RFC4609], IGMP/MLD [MLD-SEC], and PIM last-hop issues [PIM-THREATS].
しかし、マルチキャストルーティングインフラストラクチャのセキュリティの解析[RFC4609]、IGMP / MLD [MLD-SEC]、およびPIM最終ホップ問題[PIM-脅威]がありました。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、B.、およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618]フェナー、B.とD.マイヤー、 "は、Multicast Source Discovery Protocol（MSDP）"、RFC 3618、2003年10月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、RFC 3810、2004年6月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956] Savola、P.とB.ハーバーマン、 "IPv6マルチキャストアドレスでのランデブーポイント（RP）アドレスを埋め込み"、RFC 3956、2004年11月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607]ホルブルック、H.、およびB.カイン、 "IPのためのソース固有のマルチキャスト"、RFC 4607、2006年8月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T.、チャンドラ、R.、カッツ、D.、およびY. Rekhter、 "BGP-4のためのマルチプロトコル拡張機能"、RFC 4760、2007年1月。
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[RFC4915] Psenak、P.、Mirtorabi、S.、ロイ、A.、グエン、L.、およびP. Pillay-Esnault、 "OSPFにおけるマルチトポロジー（MT）ルーティング"、RFC 4915、2007年6月。
[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007.
[RFC5015]ハンドレー、M.、Kouvelas、I.、スピークマン、T.、およびL. Vicisano、 "双方向プロトコル独立マルチキャスト（BIDIR-PIM）"、RFC 5015、2007年10月。
[802.1ak] "IEEE 802.1ak - Multiple Registration Protocol", <http://www.ieee802.org/1/pages/802.1ak.html>.
[802.1ak] "IEEE 802.1ak - 複数登録プロトコル"、<http://www.ieee802.org/1/pages/802.1ak.html>。
[ADDRARCH] Savola, P., "Overview of the Internet Multicast Addressing Architecture", Work in Progress, October 2006.
[ADDRARCH] Savola、P.、「インターネットマルチキャストの概要アーキテクチャへの対応」、進歩、2006年10月に作業。
[CGMP] "Cisco Group Management Protocol", <http://www.javvin.com/protocolCGMP.html>.
[CGMP] "シスコグループ管理プロトコル"、<http://www.javvin.com/protocolCGMP.html>。
[DVMRPv3] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress, December 2003.
[DVMRPv3] Pusateri、T.、 "距離ベクトルマルチキャストルーティングプロトコル"、進歩、2003年12月の作業。
[DVMRPv3-AS] Pusateri, T., "Distance Vector Multicast Routing Protocol Applicability Statement", Work in Progress, May 2004.
[DVMRPv3-AS] Pusateri、T.、 "距離ベクトルマルチキャストルーティングプロトコルの適用性に関する声明"、進歩、2004年5月での作業。
[DYNSSM-REQ] Lehtonen, R., Venaas, S., and M. Hoerdt, "Requirements for discovery of dynamic SSM sources", Work in Progress, February 2005.
[DYNSSM-REQ] Lehtonenの、R.、Venaas、S.、およびM. Hoerdt、 "動的SSMソースの発見のための要件"、進歩、2005年2月に働いています。
[GMRP] "GARP Multicast Registration Protocol", <http://www.javvin.com/protocolGMRP.html>.
[GMRP] "GARPマルチキャスト登録プロトコル"、<http://www.javvin.com/protocolGMRP.html>。
[IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap Analysis from the MBONED Working Group for the IESG [Expired]", Work in Progress, July 2002.
[IM-GAPS]マイヤー、D.とB. Nickless、進歩、2002年7月の作業 "[期限切れ] IESGのためMBONEDワーキンググループからインターネットのマルチキャストギャップ分析"。
[IMRP-ISSUES] Meyer, D., "Some Issues for an Inter-domain Multicast Routing Protocol", Work in Progress, November 1997.
[IMRP-ISSUES]マイヤー、D.、進歩、1997年11月、作業 "ドメイン間マルチキャストルーティングプロトコルのためのいくつかの問題"。
[M-ISIS] Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in IS-IS", Work in Progress, November 2007.
[M-ISIS] Przygienda、T.、 "M-ISIS：ISISにおけるマルチトポロジー（MT）ルーティング"、進歩、2007年11月に作業。
[MCAST-ISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work in Progress, February 2005.
[MCAST-ISSUES] Savola、P.、 "IPv6マルチキャストデプロイの問題"、進歩、2005年2月に作業。
[MLD-SEC] Daley, G. and G. Kurup, "Trust Models and Security in Multicast Listener Discovery", Work in Progress, July 2004.
[MLD-SEC]デイリー、G.とG. Kurup、「信頼モデルとマルチキャストリスナ発見のセキュリティ」、進歩、2004年7月に作業。
[PIM-SNOOP] Hemige, V., "PIM Snooping over VPLS", Work in Progress, March 2007.
[PIM-SNOOP] Hemige、V.、 "VPLSオーバーPIMスヌーピング"、進歩、2007年3月に作業。
[PIM-THREATS] Savola, P. and J. Lingard, "Host Threats to Protocol Independent Multicast (PIM)", Work in Progress, October 2007.
[PIM-脅威] Savola、P.およびJ.リンガード、進歩、2007年10月の作業 "プロトコル独立マルチキャスト（PIM）へのホストの脅威"。
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[RFC1075] Waitzman、D.、ヤマウズラ、C.、およびS.デアリング、 "距離ベクトルマルチキャストルーティングプロトコル"、RFC 1075、1988年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112]デアリング、S.、STD 5、RFC 1112 "IPマルチキャスティングのためのホスト拡大"、1989年8月。
[RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993.
[RFC1458] Braudes、B.及びS. Zabele、 "マルチキャストプロトコルのための要件"、RFC 1458、1993年5月。
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[RFC1584]モイ、J.、 "OSPFへのマルチキャスト拡張機能"、RFC 1584、1994年3月。
[RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast Routing -- Protocol Specification --", RFC 2189, September 1997.
[RFC2189] Ballardie、T.、 "コアベースツリー（CBTバージョン2）マルチキャストルーティング - プロトコル仕様 - "、RFC 2189、1997年9月。
[RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[RFC2201] Ballardie、T.、 "コアベースツリー（CBT）マルチキャストルーティングアーキテクチャ"、RFC 2201、1997年9月。
[RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing Protocols", RFC 2715, October 1999.
[RFC2715]ターラー、D.、 "マルチキャストルーティングプロトコルの相互運用性規則"、RFC 2715、1999年10月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, L., Tweedly, A., Bhaskar, N., Edmonstone, R., Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport Protocol Specification", RFC 3208, December 2001.
[RFC3208]スピークマン、T.、クロウクロフト、J.、Gemmell、J.、ファリナッチ、D.、リン、S.、Leshchiner、D.、ルビー、M.、モンゴメリー、T.、リゾー、L.、Tweedly、 A.、Bhaskar、N.、Edmonstone、R.、Sumanasekera、R.、およびL. Vicisano、 "PGM信頼できるトランスポートプロトコル仕様"、RFC 3208、2001年12月。
[RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)", RFC 3446, January 2003.
[RFC3446]キム、D.、マイヤー、D.、キルマー、H.、およびD.ファリナッチ、 "エニーキャストRendevousポイント（RP）プロトコル独立マルチキャスト（PIM）とMulticast Source Discovery Protocol（MSDP）を用いた機構" を、RFC 3446 、2003年1月。
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3488]呉、I.およびT.エッカート、 "シスコシステムズルータポートグループ管理プロトコル（RGMP）"、RFC 3488、2003年2月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T.とB.ウィス、 "マルチキャストグループのセキュリティアーキテクチャ"、RFC 3740、2004年3月。
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): Protocol Specification", RFC 3913, September 2004.
[RFC3913]ターラー、D.、 "ボーダーゲートウェイマルチキャストプロトコル（BGMP）：プロトコル仕様"、RFC 3913、2004年9月。
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
[RFC3973]アダムス、A.、ニコラス、J.、およびW. Siadak、 "プロトコル独立マルチキャスト - 稠密モード（PIM-DM）：プロトコル仕様（改訂）"、RFC 3973、2005年1月。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286]ハーバーマン、B.及びJ.マーチン、 "マルチキャストルータ発見"、RFC 4286、2005年12月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541]クリステンセン、M.、キンボール、K.、およびF. Solensky、RFC 4541、2006年5月、 "インターネットグループ管理プロトコル（IGMP）とMulticast Listener Discovery（MLD）スヌーピングスイッチの考慮事項"。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
[RFC4605]フェナー、B.、彼、H.、ハーバーマン、B.、およびH. Sandick、 "インターネットグループ管理プロトコル（IGMP）/マルチキャストリスナ発見（MLD）ベースマルチキャスト転送（" IGMP / MLDプロキシ」） 」、RFC 4605、2006年8月。
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, October 2006.
[RFC4609] Savola、P.、Lehtonenの、R.、およびD.マイヤー、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）マルチキャストルーティングセキュリティの問題と機能拡張"、RFC 4609、2006年10月。
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006.
[RFC4610]ファリナッチ、D.およびY.カイ、RFC 4610、2006年8月 "Protocol Independent Multicast（PIM）を使用してエニーキャストRP-"。
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008.
[RFC5059] Bhaskar、N.、ガル、A.、リンガード、J.、およびS. Venaas、 "プロトコル独立マルチキャスト（PIM）のためのブートストラップルータ（BSR）メカニズム"、RFC 5059、2008年1月。
[RITVANEN] Ritvanen, K., "Multicast Routing and Addressing", HUT Report, Seminar on Internetworking, May 2004, <http://www.tml.hut.fi/Studies/T-110.551/2004/ papers/>.
[RITVANEN] Ritvanen、K.、 "マルチキャストルーティングおよびアドレス指定"、HUT報告書、インターネットワーキングセミナー、2004年5月、<http://www.tml.hut.fi/Studies/T-110.551/2004/論文/>。
Appendix A. Multicast Payload Transport Extensions
付録A.マルチキャストペイロード交通拡張機能
A couple of mechanisms have been specified to improve the characteristics of the data that can be transported over multicast.
機構のカップルは、マルチキャストを介して転送できるデータの特性を改善するために指定されています。
We describe those mechanisms that have impact on the multicast routing infrastructure, e.g., require or specify router assistance or involvement in some form. Purely end-to-end or host-based protocols are out of scope.
我々は、例えば、マルチキャストルーティングインフラストラクチャに影響を与える必要またはルータ支援又は何らかの形で関与を指定し、それらの機構を記載しています。純粋にエンドツーエンドまたはホストベースのプロトコル適用範囲外です。
A.1. Reliable Multicast
A.1。信頼性の高いマルチキャスト
There has been some work on reliable multicast delivery so that applications with reliability requirements could use multicast instead of simple unreliable UDP.
信頼性が要求されるアプリケーションではなく、単純な信頼性の低いUDPのマルチキャストを使用することができるように、信頼性の高いマルチキャスト配信にいくつかの作業がありました。
Most of the mechanisms are host-based and as such out of scope of this document, but one relevant from multicast routing perspective is Pragmatic Generic Multicast (PGM) [RFC3208]. It does not require support from the routers, bur PGM-aware routers may act in router assistance role in the initial delivery and potential retransmission of missing data.
メカニズムのほとんどは、ホスト・ベースであり、そのようなものとして、この文書の範囲外が、マルチキャストルーティングの観点から、関連する一つが実用汎用マルチキャスト（PGM）[RFC3208]です。これは、ルータからの支援を必要としない、イガPGM対応のルータは最初の配信と欠落データの潜在的な再送信にルータ支援の役割に作用することができます。
A.2. Multicast Group Security
A.2。マルチキャストグループのセキュリティ
Multicast Security Working Group has been working on methods how the integrity, confidentiality, and authentication of data sent to multicast groups can be ensured using cryptographic techniques [RFC3740].
マルチキャストセキュリティワーキンググループは、整合性、機密性、およびマルチキャストグループに送信されたデータの認証は、暗号技術[RFC3740]を使用して確保することができ、どのような方法に取り組んできました。
Author's Address
著者のアドレス
Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland
ペッカSavola CSC - 科学計算株式会社エスポー、フィンランド
EMail: psavola@funet.fi
メールアドレス：psavola@funet.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。