[要約] RFC 5110は、インターネットのマルチキャストルーティングアーキテクチャの概要を提供しています。このRFCの目的は、マルチキャスト通信の基本原則とプロトコルを説明し、インターネット上での効果的なマルチキャスト通信を実現するためのガイドラインを提供することです。
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),
o マルチキャストトポロジ情報の配布（セクション2.2）、
o learning active sources (Section 2.3),
o アクティブソースの学習（セクション2.3）、
o configuring and distributing the rendezvous point (RP) information (Section 2.4),
o Rendezvous Point（RP）情報の構成と配布（セクション2.4）、
o mechanisms for enhanced redundancy (Section 2.5),
o 冗長性を強化するためのメカニズム（セクション2.5）、
o interacting with hosts (Section 2.6), and
o ホストとの対話（セクション2.6）、および
o restricting the multicast flooding in the link layer (Section 2.7).
o リンク層のマルチキャスト洪水を制限する（セクション2.7）。
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:
このメモは、次のRFCを歴史的[RFC2026]に再分類します。
o Border Gateway Multicast Protocol (BGMP) [RFC3913],
o Border Gatewayマルチキャストプロトコル（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
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アドレス（ES）を知る必要があります（セクション2.4、セクション2.5）。IPv4を使用すると、RPSをMSDPを使用して他のRPSに接続する必要があるため、他のRPSに接続されたソースに関する情報を分布させることができます（セクション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).
ホストが送信を受信したい場合、さまざまな手段（SDP説明ファイル[RFC4566]など）を使用して、マルチキャストグループアドレス（およびSSM、ソースアドレス）を見つける必要があります。次に、IGMP（IPv4）またはMLD（IPv6）（セクション2.6）を使用して、最初のホップルーターへの関心を示します。ルーターは、ホップバイホップマルチキャスト転送状態（セクション2.1）のセットアップをソース（SSM）または最初（ASM）から最初に設定します。ルーターはRPを使用して、グループのすべてのソースを見つけます（セクション2.3）。マルチキャストトランスミッションがレシーバーの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は、RPSを使用せず、代わりに受信機が（ソース、グループ）ペアを知っており、明示的に信号を知っていることを要求する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は、UnicastトンネルでLANからRPまでのマルチキャストパケットをカプセル化します。PIM-SMは、グループの関心のある受信機で構成される単方向のグループ固有の分布ツリーを構築します。当初、マルチキャスト分布ツリーはRPに根付いていますが、後にDRSには、建物（ソース、グループ）固有のツリーによる配信を最適化するオプションがあります。
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]は、サイトのほぼすべてのサブネットがグループの少なくとも1つの受信機を持っていると仮定しました。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-DMからPIM-SMへの移行は簡単でした。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のAuto-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]は、マルチキャスト用に設計された最初のプロトコルでした。初期展開ハードルを回避するために、マルチキャストトポロジ機能の一部であるトンネリング機能も含まれています。
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）に基づいているため、ドメイン間のケースにはスケーリングされていないため、オペレーターはドメイン内とドメイン間の両方で使用する単一のプロトコルを展開する方が簡単であることがわかりました。ネットワークなので、積極的に展開されなくなりました。
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.
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].
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-SPARSEモードがドメイン間展開されている唯一のマルチキャストルーティングプロトコルであり、したがって、マルチキャストドメインでも最も頻繁に使用されることは明らかです。
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はデファクトマルチキャスト転送プロトコルになりましたが、その名前が示すように、それは基礎となるユニキャストルーティングプロトコルとは無関係です。ユニキャストとマルチキャストのトポロジが同じ（「一致」）、つまり同じルーティングテーブル（ルーティング情報ベース、リブ）を使用する場合、プロトコルと併用する到達可能性情報のセットを配布するのに十分であると考えられています。これにより、マルチキャスト転送状態（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）のさまざまな到達可能性情報。Multiprotocol BGPは長年にわたって広く展開されており、IPv6をルーティングするためにも必要です。Safi = 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と同様に、一部のインテリアゲートウェイプロトコル（IGPS）は、IS-ISマルチトポロジー拡張[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.
興味深いケースは、一部のルーターがマルチキャストトポロジー情報を明示的に配布しない場合に発生しますが、他のケースは発生します。特に、これはインターネット内の一部のマルチキャストサイトがプレーンBGPを使用しているが、MBGPを使用している場合に発生します。
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を使用する場合、マルチキャスト対応サイトは、トポロジーが「はい、はい、マルチキャストを使用します」と明示的に信号を送るためにトポロジーが一致していても、マルチキャストにはMP-BGP SAFI = 2、ユニキャストにSAFI = 1を使用することをお勧めします。。
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 SAFI = 3が定義され、適用できる一方で、仕様の一部は実装されておらず、実際には使用できないことを意味します。「はい」には、一般的に適用可能で、機能することが知られているメカニズムがリストされています。「少数のインプレム」。アプローチが機能する可能性があるが、一般的には利用できないことを意味します。
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では、RPSはローカル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]を支援する帯域外のソース発見機能を分析および/または定義する試みがあります。
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は、単一のドメインで複数のRP間のソースに関する状態を共有するためにも使用されます[RFC3446]。PIM拡張[RFC4610]を使用して同じことを実現できます。詳細については、セクション2.5を参照してください。
There is no intent to define MSDP for IPv6, but instead use only SSM and Embedded-RP [MCAST-ISSUES].
IPv6のMSDPを定義する意図はありませんが、代わりにSSMと埋め込みRP [MCAST-ISSUE]のみを使用します。
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とそれについて状態を共有する必要はありません。必要に応じて、PIM [RFC4610]を使用してAnycast-RPで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マッピングは最適ではないと見なされました。ただし、Anycast RPのアドレス指定により、RPアドレスが変更される可能性は低いです。したがって、管理上の負担は一般に初期構成に限定されます。通常、すべてのルーターに必要なマルチキャスト構成がかなりあるため（たとえば、すべてのインターフェイスのPIM）、RPアドレスを静的に追加することは実際には問題ではありません。さらに、静的なAnycast RPマッピングは、Auto-RPやBootstrapルーター（BSR）などの動的メカニズムに見られる複雑さなしに、RP負荷共有と冗長性の利点（セクション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].
このような設計により、Anycast RPは、現在RPSとして機能するルーターのループバックインターフェイスで構成されているアドレスを使用し、状態はPIM [RFC4610]またはMSDP [RFC3446]を使用して分布しています。
Using this technique, each router might only need to be configured with one, portable RP address.
この手法を使用して、各ルーターは、ポータブルRPアドレスを1つで構成するだけでいい場合があります。
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.
Embedded-RPは、RPを使用する人に委任されるグループアドレスのRPのアドレスに関する情報を提供するため、埋め込まれたRP以外のASMが使用されない限り、ネットワーク管理者は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のアドレスはユーザーとアプリケーションにさらされているため、たとえば、Anycastアドレスの手動構成を使用することにより、頻繁に変更されないようにすることが非常に重要です。
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.
CiscoのAuto-RPは、BSRと同様に、グループをRPマッピングに分配するための古い独自の方法です。Auto-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.
Auto-RPとBSRの両方は、有効なルーターのみがRPSとして自分自身を宣伝できるようにするために、ルーターで何らかの形の制御を必要とします。さらに、PIM Bordersでは、BSRおよびAuto-RPメッセージの洪水を防ぐ必要があります。さらに、ルーターは実際に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.
手動で構成されたAnycast-RPアドレスを使用する前にAUTO-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が1つしかないことは、マルチキャストドメイン全体の単一の障害ポイントです。その結果、RP機能を排除するか、RPSの冗長性、障害に対する回復力を強化し、障害から迅速に回復するための多くのメカニズムが開発されました。このセクションは、これらの手法を明示的に要約しています。
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は、単一のドメインの複数のRP間のソースに関する状態を共有するためにも使用されます。たとえば、冗長性[RFC3446]。このコンテキストでの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.
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アドレスに移動する場合があります。SSM送信者は、受信機が新しいチャネルに参加したり、送信者が受信機に透明なIPモビリティテクニックを使用したりしない限り、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.
独自のソリューションであるCiscoの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.
Cisco独自のCGMP [CGMP]は、ルーターがスイッチに通知するソリューションを提供しますが、スイッチがIGMPパケットをSnoopにして、グループを受信したくないホストのより速い通知を有効にすることもできます。CGMPの実装は、IGMPV3での高速休暇動作をサポートしていません。IGMPV1およびIGMPV2のIGMPレポート抑制により、マルチキャストは、リンクに少なくとも1つのレシーバーがある限り、かつてグループのメンバーだったポートに浸水しています。洪水制限は、マルチキャスト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は、IEEE 802.1AK [802.1AK]で指定されている複数の登録プロトコル（MRP）およびマルチキャスト複数登録プロトコル（MMRP）に置き換えられたGARPとGMRPの廃止を考慮します。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 Snooping [RFC4541]は、最も広く実装されている手法のようです。IGMPスヌーピングでは、スイッチがかなりの量のIPレベルパケット検査を実装する必要があります。これは正しくなるのが難しいものであるように思われ、多くの場合、アップグレードも課題です。Snooping SupportはIgmpv1およびIgmpv2の一般的ですが、Igmpv3またはMLD（任意のバージョン）のスヌーピングをサポートするスイッチが少ないです。最悪の場合、IGMPV3スヌーピングブレークをサポートしないスイッチでIGMPスヌーピングを有効にして、IGMPV3を使用してノードのマルチキャスト機能をブレークします。
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 snooping at LANs is that PIM messages can't be turned off or encrypted, leading to security issues [PIM-THREATS].
スヌーピングスイッチは、ルーターが存在するポートを識別し、したがってパケットに浸水する場所も識別する必要があります。これは、マルチキャストルーターディスカバリープロトコル[RFC4286]を使用して実現できます。特定のIGMPクエリ[RFC4541]を調べ、PIM Helloやその他のメッセージ、または手動で構成を検討します。LANSでのPIMスヌーピングの問題は、PIMメッセージをオフまたは暗号化できず、セキュリティの問題につながることです[PIM-Threats]。
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.
レナード・ジュリアーノ、ジェームズ・リンガード、ジャン・ジャック・パンシオット、デイブ・マイヤー、スティグ・ヴェナス、トム・プサテリ、マーシャル・ユーバンクス、ディノ・ファリナッチ、バラト・ジョシ、アルバート・マンフレディ、ジャン・ジャックパンシオット、スペンサー・ドーキンズ、ダン・チシュルム、ダン・チシュルム、ダン・チシュルム、ダン・チシュルム、ダン・チシュルム、Morin、Ron Bonica、Prashant Jhingran、およびTim Polkは良いコメントを提供し、この文書の改善に役立ちました。
IANA has updated the following registries by adding a reference to this document:
IANAは、このドキュメントへの参照を追加することにより、次のレジストリを更新しました。
o OSPFv2 Options Registry: MC-bit
o OSPFV2オプションレジストリ：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ルータープロパティレジストリ：W-BIT O OSOSPFV3オプションレジストリ：MCビット
o OSPFv3 LSA Function Code Registry: Group-membership-LSA
o OSPFV3 LSA関数コードレジストリ：グループメンバーシップLSA
o OSPFv3 Prefix Options Registry: MC-bit
o OSPFV3プレフィックスオプションレジストリ：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 Last-Hopの問題[PIM-Threats]のセキュリティの分析があります。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、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] Cain、B.、Deering、S.、Kouvelas、I.、Fenner、B。、およびA. Thyagarajan、「インターネットグループ管理プロトコル、バージョン3」、RFC 3376、2002年10月。
[RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", RFC 3618, October 2003.
[RFC3618] Fenner、B。およびD. Meyer、「マルチキャストソースディスカバリープロトコル（MSDP）」、RFC 3618、2003年10月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810] Vida、R。およびL. Costa、「IPv6のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、RFC 3810、2004年6月。
[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. Haberman、「IPv6マルチキャストアドレスにRendezvous Point（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] Fenner、B.、Handley、M.、Holbrook、H.、およびI. Kouvelas、 "Protocol Independent Multicast -Sparse Mode（PIM -SM）：Protocol Specification（改訂）、RFC 4601、2006年8月。
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
[RFC4607] Holbrook、H。およびB. Cain、「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] Bates、T.、Chandra、R.、Katz、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.、Roy、A.、Nguyen、L。、およびP. Pillay-Esnault、「Multi-Topology（MT）Routing in OSPF」、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] Handley、M.、Kouvelas、I.、Speakman、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月、Work in Progress。
[CGMP] "Cisco Group Management Protocol", <http://www.javvin.com/protocolCGMP.html>.
[CGMP]「Cisco Group Management Protocol」、<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 Multicast登録プロトコル」、<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] Meyer、D。およびB. Nickless、「IESG [期限切れ]のためのMbonedワーキンググループからのインターネットマルチキャストギャップ分析」、2002年7月の作業。
[IMRP-ISSUES] Meyer, D., "Some Issues for an Inter-domain Multicast Routing Protocol", Work in Progress, November 1997.
[IMRP-Issues] Meyer、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：IS-ISでのマルチトポロジー（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] Daley、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-Threats] Savola、P。およびJ. Lingard、「プロトコル独立マルチキャスト（PIM）に対するホストの脅威」、2007年10月、進行中の作業。
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[RFC1075] Waitzman、D.、Partridge、C。、およびS. Deering、「距離ベクトルマルチキャストルーティングプロトコル」、RFC 1075、1988年11月。
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast Protocols", RFC 1458, May 1993.
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[RFC1584] Moy、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] Thaler、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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（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] 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。、および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.ファリナッチ、「プロトコル独立マルチキャスト（PIM）およびマルチキャストソースディスカバリープロトコル（MSDP）を使用したAnycast Rendevous Point（RP）メカニズム」、RFC 3446、2003年1月。
[RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group Management Protocol (RGMP)", RFC 3488, February 2003.
[RFC3488] Wu、I。およびT. Eckert、「Cisco Systems Router-Port-Port Group Management Protocol（RGMP）」、RFC 3488、2003年2月。
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004.
[RFC3740] Hardjono、T。およびB. Weis、「The Multicast Group Security Architecture」、RFC 3740、2004年3月。
[RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): Protocol Specification", RFC 3913, September 2004.
[RFC3913] Thaler、D。、「Border Gateway Multicast Protocol（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] Adams、A.、Nicholas、J。、およびW. Siadak、「プロトコル独立マルチキャスト - 密度モード（PIM -DM）：プロトコル仕様（改訂）」、RFC 3973、2005年1月。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286] Haberman、B。およびJ. Martin、「マルチキャストルーターディスカバリー」、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] Christensen、M.、Kimball、K。、およびF. Solensky、「インターネットグループ管理プロトコル（IGMP）およびマルチキャストリスナーディスカバリー（MLD）スヌーピングスイッチに関する考慮事項」、RFC 4541、2006年5月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「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] Fenner、B.、He、H.、Haberman、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. Meyer、「プロトコル独立マルチキャスト - スパースモード（PIM -SM）マルチキャストルーティングセキュリティの問題と機能強化」、RFC 4609、2006年10月。
[RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol Independent Multicast (PIM)", RFC 4610, August 2006.
[RFC4610] Farinacci、D。およびY. Cai、「プロトコル独立マルチキャスト（PIM）を使用したAnycast-RP」、RFC 4610、2006年8月。
[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.、Gall、A.、Lingard、J。、およびS. Venaas、「ブートストラップルーター（BSR）プロトコル独立マルチキャスト（PIM）のメカニズム」、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 Report、InternetWorkingのセミナー、2004年5月、<http://www.tml.hut.fi/studies/t-10.551/2004/ Papers/>。
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.
マルチキャストルーティングインフラストラクチャに影響を与えるメカニズムについて説明します。たとえば、ルーターの支援または何らかの形での関与を必要とするか指定します。純粋にエンドツーエンドまたはホストベースのプロトコルは範囲外です。
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]です。ルーターからのサポートは必要ありません。BURPGM対応のルーターは、最初の配信と欠落データの再送信の可能性においてルーター支援の役割で作用する場合があります。
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
Pekka Savola CSC -Scientific Computing Ltd. Espoo Finland
EMail: psavola@funet.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。