RFC5110 日本語訳

5110 Overview of the Internet Multicast Routing Architecture. P.Savola. January 2008. (Format: TXT=56217 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          P. Savola
Request for Comments: 5110                                     CSC/FUNET
Category: Informational                                     January 2008

Savolaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 5110年のCSC/FUNETカテゴリ: 情報の2008年1月

        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.

また、このメモは数個の、より古いRFCsにHistoricに分類し直します。 これらのRFCsは広く決して配備されなかったか、または不要になったマルチキャストルーティング・プロトコルについて説明します。

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

1. 序論…3 1.1. マルチキャスト関連の略語…4 2. マルチキャストルート設定…4 2.1. マルチキャスト推進状態を設立します…5 2.1.1. PIM-Sm…5 2.1.2. PIM-DM…5 2.1.3. 双方向の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. 相互作用と概要…7 2.2. トポロジー情報を分配します…8 2.2.1. Multiprotocol BGP…8 2.2.2. OSPF/、-、マルチトポロジー拡大…9 2.2.3. 以下を発行してください。 ユニキャスト/マルチキャストトポロジーを重ね合わせます…9 2.2.4. 概要…10 2.3. (アクティブ)のソースを学びます…10 2.3.1. SSM…11 2.3.2. MSDP…11 2.3.3. 埋め込まれたRP…11 2.3.4. 概要…12

Savola                       Informational                      [Page 1]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[1ページ]のRFC5110マルチキャスト

      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

2.4. PIM RP情報を構成して、分配します…12 2.4.1. 手動のRP構成…12 2.4.2. 埋め込まれたRP…13 2.4.3. BSRと自動RP…13 2.4.4. 概要…14 2.5. 高められた冗長のためのメカニズム…14 2.5.1. Anycast RP…14 2.5.2. 国がないRPフェイルオーバー…14 2.5.3. 双方向のPIM…15 2.5.4. 概要…15 2.6. ホストとの相互作用…15 2.6.1. マルチキャストを送るホスト…15 2.6.2. マルチキャストを受けるホスト…15 2.6.3. 概要…16 2.7. リンクでのマルチキャスト氾濫を制限して、層にしてください…16 2.7.1. ルータからルータへの氾濫減少…16 2.7.2. ホスト/ルータ氾濫減少…17 2.7.3. 概要…18 3. 承認…18 4. IANA問題…18 5. セキュリティ問題…19 6. 参照…19 6.1. 標準の参照…19 6.2. 有益な参照…20 付録A.マルチキャスト有効搭載量輸送拡大…24 A.1。 信頼できるマルチキャスト…24 A.2。 マルチキャストグループセキュリティ…24

Savola                       Informational                      [Page 2]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[2ページ]のRFC5110マルチキャスト

1.  Introduction

1. 序論

   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 ランデブーを構成して、広げると、(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はどうこれらのクラスのメカニズムに一緒に合い始めるか。 また、いくつかのマルチキャストデータ伝送問題がAppendix Aで紹介されます。

   This memo reclassifies to Historic [RFC2026] the following RFCs:

このメモはHistoric[RFC2026]に以下のRFCsに分類し直します:

   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]で見つけられるかもしれません。

Savola                       Informational                      [Page 3]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[3ページ]のRFC5110マルチキャスト

1.1.  Multicast-Related Abbreviations

1.1. マルチキャスト関連の略語

   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も一般的なルータDVMRPディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコルガープ(IEEE 802.1D-2004)のプロトコルIGMPインターネット集団経営プロトコル属性登録プロトコルGMRPガープマルチキャスト登録MBGP Multiprotocol BGP(**「マルチキャストBGP」でない)MLDマルチキャストリスナー発見MRP複数の(IEEE 802.1ak)登録プロトコルに指定されたベースのルータの木のCGMPコクチマス集団経営プロトコルCBTコアDRを独力で進みます; MMRP(IEEE 802.1ak)ソースの発見のプロトコルのPGM実益主義のマルチキャスト倍数登録プロトコルMOSPFマルチキャストOSPF MSDPマルチキャスト司令官のマルチキャストのPIMのプロトコルの独立しているマルチキャストPIM-DM PIM--濃いモードPIM-Sm PIM--まばらなモードPIM-SSM PIM--ソース特有のマルチキャストRGMP(シスコのもの)の逆のその後のルータのセッション記述プロトコルSSMソース特有の集団経営プロトコルRPランデブーポイントRPF経路推進サフィアドレス家族識別子SDPマルチキャスト

2.  Multicast Routing

2. マルチキャストルート設定

   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は、他のRPsに接続されたソースの情報を分配できる(セクション2.3)ようにMSDPを使用することで他のRPsに接続される必要があります。 さらに、ルータが、知る必要がある、マルチキャストトポロジーはユニキャストトポロジーと異なっています、そして、または、ルーティング・プロトコル拡大はどう、その情報(セクション2.2)を提供できるか。

Savola                       Informational                      [Page 4]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[4ページ]のRFC5110マルチキャスト

   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の)か最初に、RP(ASMの)を通してホップごとのマルチキャスト推進状態(セクション2.1)に設定を開始します。 ルータは、グループ(セクション2.3)に関してすべてのソースを見つけるのにRPを使用します。 マルチキャスト送信が受信機のLANに到着して、IGMP詮索などの氾濫減少が採用していない場合(セクション2.7)、それはあらゆるイーサネットスイッチポートへあふれます。

2.1.  Setting up Multicast Forwarding State

2.1. マルチキャスト推進状態を設立します。

   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.

マルチキャストルーティングの最も重要な部分は、状態を進めながら、マルチキャストをセットアップしています。 推進州にはタイムアウトがあるので、州の維持が周期的なメッセージングを必要とします。 このセクションは一般的にこのために使用されるプロトコルについて説明します。

2.1.1.  PIM-SM

2.1.1. PIM-Sm

   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プロトコルはAny Source Multicast(ASM)とSource特有のMulticast(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はユニキャストトンネルのLANからRPまで出典を明示されたマルチキャストパケットをカプセルに入れります。 PIM-SMは単方向、グループの関心がある受信機のグループ特有の分配木の成ることを建てます。 初めは、マルチキャスト分配木はRPに根づきますが、後で、DRsには、特定の木を建てることによって(ソースは分類してください)配送を最適化するオプションがあります。

   A more lengthy introduction to PIM-SM can be found in Section 3 of
   [RFC4601].

[RFC4601]のセクション3でPIM-SMへの、より長い紹介を見つけることができます。

2.1.2.  PIM-DM

2.1.2. PIM-DM

   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はネットワーク(「あふれて、剪定する」)中にマルチキャスト送信をあふれさせます。

Savola                       Informational                      [Page 5]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[5ページ]のRFC5110マルチキャスト

   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-DMからPIM-SMに移行するのは、コンパチブルパケット・フォーマットを使用するように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.

また、Sparseモードがデフォルトで使用されますが、Denseが構成されたマルチキャストグループ範囲(セクション2.4.3におけるAuto-RPなどの)だけに使用されるところで多くの実現がいわゆる「まばらに濃い」構成を支持します。 最近、多くのネットワークがまばらにまばらにだけ濃いモードから遠くで移行しました。

2.1.3.  Bidirectional PIM

2.1.3. 双方向のPIM

   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を使用するためにグループ範囲を構成するために、相互ドメイン解決策は全くありません。

2.1.4.  DVMRP

2.1.4. DVMRP

   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.

現在、PIM-SMに取り替えて、DVMRPはオペレータネットワークにめったにだけ使用されません。 DVMRPを支持するだけである遺産ファイアウォールから内部のネットワークまで走るために、DVMRPの最も典型的な展開は葉のネットワークにあります。 しかしながら、Genericルート設定Encapsulation(GRE)トンネリング[RFC2784]はこの機能性でDVMRPに追いついたように思えます、そして、遺産展開以外のDVMRPの比較的少ない使用があります。

Savola                       Informational                      [Page 6]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[6ページ]のRFC5110マルチキャスト

2.1.5.  MOSPF

2.1.5. MOSPF

   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]はいくつかの業者によって実行されて、イントラドメインネットワークで何らかの展開を見ました。 しかしながら、イントラドメインオープンShortest Path First(OSPF)に基づいているので、相互ドメインケースに比例しないで、オペレータは、両方のイントラドメインと相互ドメインネットワークにおける使用のためにただ一つのプロトコルを配備するのが、より簡単であるのでそれがもう活発に配備されていないのがわかりました。

2.1.6.  BGMP

2.1.6. BGMP

   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標準化過程で採用されて、サービスプロバイダー共同体の中の十分なサポートが前方へ動くのをさせませんでした。 生産実現にもかかわらず、生産展開は全く報告されませんでした。

2.1.7.  CBT

2.1.7. CBT

   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は生産展開を決して見ませんでした。

2.1.8.  Interactions and Summary

2.1.8. 相互作用と概要

   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)のようなグループかメカニズムの手動の構成を通常必要とします。 また、異なったプロトコルの間に相互作用するのも可能です。 例えば、しかし、葉のネットワーク、PIM-SMで上流へDVMRPを使用してください。 異なったプロトコルの中の相互作用のための基礎は[RFC2715]に概説されています。

   The following figure gives a concise summary of the deployment status
   of different protocols as of this writing.

以下の図はこの書くこと現在、異なったプロトコルの展開状態の簡潔な概要をします。

Savola                       Informational                      [Page 7]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[7ページ]のRFC5110マルチキャスト

                +--------------+--------------+----------------+
                | 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 |
   +------------+--------------+--------------+----------------+

+--------------+--------------+----------------+ | 相互ドメイン| イントラドメイン| 状態| +------------+--------------+--------------+----------------+ | PIM-Sm| はい| はい| アクティブ| | PIM-DM| それ以上でない| それ以上でない| 少ない使用| | BIDIR-PIM| いいえ| はい| ある理解力| | DVMRP| それ以上でない| スタッブ専用| 出かけます。| | MOSPF| いいえ| それ以上でない| 不活発| | CBT| いいえ| いいえ| 決して展開しません。| | BGMP| いいえ| いいえ| 決して展開しません。| +------------+--------------+--------------+----------------+

   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まばらなModeが配備された相互ドメインである唯一のマルチキャストルーティング・プロトコルであり、したがって、また、マルチキャストドメインの中で最も頻繁に使用されるのは、明確です。

2.2.  Distributing Topology Information

2.2. トポロジー情報を分配します。

   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はデファクトマルチキャスト推進プロトコルになりましたが、名前が含意するように、それは基本的なユニキャストルーティング・プロトコルから独立しています。 ユニキャストとマルチキャストtopologiesが同じくらい(「一致している」)、すなわち、同じルーティングが見送る使用(ルーティング情報ベース、RIB)、それがただマルチキャスト推進状態(例えば、PIM-SM)を設立するプロトコルに関連して使用されるために1セットの可到達性情報を分配するために十分であると考えられたということであるときに。

   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.

トポロジー情報が、マルチキャスト送信の効率的な分配を実行して、Reverse Path Forwarding(RPF)チェックにそれを適用することによってトランスミッション輪を防ぐのに必要です。

   This subsection introduces these protocols.

この小区分はこれらのプロトコルを紹介します。

2.2.1.  Multiprotocol BGP

2.2.1. Multiprotocol BGP

   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

"MBGP"として; しかしながら、"MBGP"が*でないのが表す*をすることに注意する価値があります。BGP-4[RFC4760]のためのMultiprotocol Extensions、(しばしば言及される、「マルチキャストBGP」) ユニキャスト(サフィは1と等しい)とマルチキャスト交通(サフィ=2)に異なった可到達性情報を分配するのにBGPを使用できるメカニズムを指定します。 Multiprotocol BGPは広くそうです。

Savola                       Informational                      [Page 8]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[8ページ]のRFC5110マルチキャスト

   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.

長年展開して、また、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がユニキャストトポロジー情報を分配するのにどこで使用されても、これらの拡大は普及使用中です。 topologiesがマルチキャストの可到達性に関するはっきりした説明を作るために一致していても、BGPを使用するマルチキャストで可能にされたネットワークは、明らかにマルチキャスト可到達性情報を分配するのにMultiprotocol BGPを使用するべきです。 多くの重要なマルチキャストトランジットプロバイダーがこれを必要とさえします、唯一明らかに広告を出したマルチキャストアドレス家族に基づくRPFルックアップをすることによって。

2.2.2.  OSPF/IS-IS Multi-Topology Extensions

2.2.2. OSPF/、-、マルチトポロジー拡大

   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と同様です、また、例えば、いくつかのInteriorゲートウェイプロトコル(IGPs)が合図の異なったtopologiesに能力を供給する、-、マルチトポロジー拡大[Mイシス]。 ユニキャストと異なっているマルチキャストトポロジーにこれらを使用できます。 同様の、しかし、それほど広く実行されなかった仕事は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-イシス/OSPFよりMBGPのずっと多くの展開を見て、イントラドメイン不適合がそうではありませんが。 一般的に配備されたネットワークはプロトコル取り扱いイントラドメイン不適合なしでよく管理されました。 しかしながら、マルチトポロジーメカニズムの有用性はトンネルなどの通常使用された次善策を一部取り替えるかもしれません。

2.2.3.  Issue: Overlapping Unicast/Multicast Topology

2.2.3. 以下を発行してください。 ユニキャスト/マルチキャストトポロジーを重ね合わせます。

   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

代替的アプローチはマルチキャストの組合で最も長い接頭語マッチとユニキャスト経路指定テーブルを使用することです。 ここの実現のテクニックはマルチキャスト経路指定テーブルに全体のユニキャスト経路指定テーブルをコピーすることです。 重要は、もっとも、ここで覚えているために指して、あります。

Savola                       Informational                      [Page 9]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[9ページ]のRFC5110マルチキャスト

   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.

別の実行されたアプローチは、ただユニキャスト経路指定テーブルの情報を調べて、そんなに適宜変化するユーザ能力を提供することです、例えば上で議論したコピー機能を使用して。

2.2.4.  Summary

2.2.4. 概要

   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を使用するなら、マルチキャストで可能にされたサイトがユニキャストにマルチキャストとサフィ=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.  |
   +----------------------+----------------+--------------+

+----------------+--------------+ | 相互ドメイン| イントラドメイン| +--------------------- +----------------+--------------+ | MP-BGPサフィ=2| はい| はい| | MP-BGPサフィ=3| 働いていません。| 働いていません。| | -、マルチトポロジー| 適切でない| はい| | OSPFマルチトポロジー| 適切でない| わずかな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である間に定義された手段を扱わないで、適用できて、仕様のその部分を実行していなくて、実際には使用できません。 「はい」は一般に適切で仕事に知られているメカニズムを記載します。 「わずかなimplem」 しかしアプローチが扱うことができた手段は一般的に利用可能ではありません。

2.3.  Learning (Active) Sources

2.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がイントラドメインで使用されるとき、その結果、ソースはプロトコル自体の特徴として学習されます。

Savola                       Informational                     [Page 10]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[10ページ]のRFC5110マルチキャスト

   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.

このセクションは相互ドメイン環境で当てはまる活発なソースについて知るオプションについて論じます。

2.3.1.  SSM

2.3.1. SSM

   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.

ソース特有のMulticast[RFC4607](また、時々「単独のソースMulticast」と呼ばれる)は、ネットワークで活発なソースを学ぶのを頼りにしません。 受取人が、ソース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].

この書くこと現在、特にSSM[DYNSSM-REQ]を助けるバンドの出ているソース発見機能を分析する、そして/または、定義する試みがあります。

2.3.2.  MSDP

2.3.2. MSDP

   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.

停止ギャップメカニズム、複数のPIM-SMドメイン(そして、RPs)がネットワークで必要であったのがいつ明らかになったか、そして、および活発なソースの情報が、PIM-SMドメインの間である他のプロトコルを使用することで伝播される必要があったとき、マルチキャストSourceディスカバリープロトコル[RFC3618]は発明されました。

   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も単一領域の複数のRPsの間のソースに関する状態を共有するのにおいて使用されています、例えば、冗長目的[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とEmbedded-RP[MCAST-ISSUES]だけを使用してください。

2.3.3.  Embedded-RP

2.3.3. 埋め込まれたRP

   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の使用を避けるのはまだ、複数のマルチキャストドメイン(伝統的な意味で)を許容している間、可能です。

Savola                       Informational                     [Page 11]

RFC 5110               Multicast Routing Overview           January 2008

概要2008年1月に掘られるSavolaの情報[11ページ]のRFC5110マルチキャスト

   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アドレスを定義することによって働いているので、それに関していかなる他のRPsとも状態を共有する必要は全くありません。 必要なら、Anycast-RPがPIM[RFC4610]を使用している状態で、まだRP冗長を達成できます。

2.3.4.  Summary

2.3.4. 概要

   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          |
   +----------------------+------+------+------------------------------+

+------+------+------------------------------+ | IPv4| IPv6| 状態| +----------------------+------+------+------------------------------+ | Bidir単一領域| はい| はい| イントラドメインだけのない、OK| | PIM-SM単一領域| はい| はい| OK| | MSDPとのPIM-Sm| はい| いいえ| デファクトv4相互ドメインASM| | 埋め込まれた-RPとのPIM-Sm| いいえ| はい| 最も良い相互ドメインASMオプション| | SSM| はい| はい| 主要な理解力がない、まだ。| +----------------------+------+------+------------------------------+

2.4.  Configuring and Distributing PIM RP Information

2.4. PIM RP情報を構成して、分配します。

   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構成メカニズム(ルータにそれらのRPsを使用することになっているRPアドレスとグループを構成するのに使用される)は存在しています。 このセクションはアプローチについて概説します。

2.4.1.  Manual RP Configuration

2.4.1. 手動の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 Router(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]を使用することで分散されています。

Savola                       Informational                     [Page 12]

RFC 5110               Multicast Routing Overview           January 2008

概要2008年1月に掘られるSavolaの情報[12ページ]のRFC5110マルチキャスト

   Using this technique, each router might only need to be configured
   with one, portable RP address.

このテクニックを使用して、各ルータは、1、携帯用のRPアドレスによって構成される必要があるだけであるかもしれません。

2.4.2.  Embedded-RP

2.4.2. 埋め込まれた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を使用する人へ代表として派遣されるグループアドレスのRPのアドレスの情報を前提とするので、Embedded-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.

多くの場合、Embedded-RPがIPv6に十分である間、Embedded-RPを除いて、サービスをASMに供給する1つの必要性がアドレスを分類するなら、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アドレスの手動の構成を使用することによって。

2.4.3.  BSR and Auto-RP

2.4.3. BSRと自動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に、Embedded-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.

シスコのAuto-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.

Auto-RPとBSRの両方が、有効なルータだけがRPsとして自分を売り込むことができるのを保証するためにルータで何らかの形式のコントロールを必要とします。 さらに、PIM境界でBSRとAuto-RPメッセージの氾濫を防がなければなりません。 それらはモニターですが、ルータは、例えば、ルータ(多分顧客のコントロールにおける)であるなら不適当に自分を売り込むのが、さらに、そうであることを実際に管理者が、彼らが使用するべきであると考えるRP(s)を使用することで必要とします。 また、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の両方が配布されたことに注意する価値がある、(例えば、まばらで、濃いのと、双方向、)、ダイナミックなファッションで。

Savola                       Informational                     [Page 13]

RFC 5110               Multicast Routing Overview           January 2008

概要2008年1月に掘られるSavolaの情報[13ページ]のRFC5110マルチキャスト

2.4.4.  Summary

2.4.4. 概要

   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発見メカニズムとそれらの状態をまとめます。 Embedded-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               |
   +--------------------+------+------+-----------------------+

+------+------+-----------------------+ | IPv4| IPv6| 展開| +--------------------+------+------+-----------------------+ | 静的なRP| はい| はい| 特にISPで| | 自動RP| はい| いいえ| レガシー展開| | BSR| はい| はい| いくつかと、anycastにより簡単です。| | 埋め込まれたRP| いいえ| はい| 成長します。| +--------------------+------+------+-----------------------+

2.5.  Mechanisms for Enhanced Redundancy

2.5. 高められた冗長のためのメカニズム

   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ドメインに1RPしか持たないのは、全体のマルチキャストドメインへの1ポイントの失敗でしょう。 その結果、RPの機能性を排除するか、失敗に対してRPsの冗長、弾力を高めて、またはすぐに障害を修復するために多くのメカニズムを開発してあります。 このセクションは明らかにこれらのテクニックをまとめます。

2.5.1.  Anycast RP

2.5.1. Anycast 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も単一領域の複数のRPsの間のソースに関して状態を共有するのにおいて使用されています、例えば、冗長目的[RFC3446]のために。 この文脈のMSDPの目的は同じグループがサービスの丈夫さを高めるように複数のRPsの同じ州の情報を共有することです。

   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の両方に効き目があります。

2.5.2.  Stateless RP Failover

2.5.2. 状態がないRPフェイルオーバー

   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.

Anycast RPシェアは、RPsの間にしたがって、そのRPの故障が小さい騒動だけを引き起こすと述べますが、また、状態がないアプローチも、より限られた弾性で可能です。 伝統的なメカニズムはアクティブなものが失敗したとき、別のRPを選択するのに、Auto-RPかBSR(セクション2.4.3を見る)を使用することです。 しかしながら、ダイナミックなメカニズムの複雑さなしで共有されたユニキャストRPアドレス(「州の共有のないanycast RP」)を使用することで同じ機能性を達成できるでしょう。 さらに、今日、かなり大規模な失敗緩和戦略を提供するのであるAnycast RPは、実際に非常に少ししか状態がないフェイルオーバーメカニズムを使用する必要がありません、特にダイナミックなもの、冗長目的のために。

Savola                       Informational                     [Page 14]

RFC 5110               Multicast Routing Overview           January 2008

概要2008年1月に掘られるSavolaの情報[14ページ]のRFC5110マルチキャスト

2.5.3.  Bidirectional PIM

2.5.3. 双方向のPIM

   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が双方向であるところで特にシナリオ(例えば、ユニキャストルーティング変化)で、より急速に一点に集まるかもしれません。Designated Forwarder選挙をやり直すのが必要です。

2.5.4.  Summary

2.5.4. 概要

   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|
   +--------------------+------+------------------------------+

+------+------+-----------------------+ | IPv4| IPv6| 展開| +--------------------+------+------+-----------------------+ | MSDPとAnycast RP| はい| いいえ| デファクトアプローチ| | PIMとAnycast RP| はい| はい| より新しいアプローチ| | 状態がないRPは失敗します。 | はい| はい| 騒動を引き起こします。| | BIDIR-PIM| はい| はい| いくつかのサイトでは、展開します。| +--------------------+------+------------------------------+

2.6.  Interactions with Hosts

2.6. ホストとの相互作用

   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.

前項はマルチキャストルーティングができるためにルータによって必要とされたコンポーネントに対処しました。 明らかに、マルチキャストのリアル・ユーザはホストです: マルチキャストを送るか、または受けます。 このセクションはホストとの必要な相互作用について説明します。

2.6.1.  Hosts Sending Multicast

2.6.1. マルチキャストを送るホスト

   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.

イントラドメインかEmbedded-RPシナリオでは、ASM送付者は彼らのトランスミッションの配送のときに重要な影響なしで新しいIPアドレスに移行するかもしれません。 受信機が新しいチャンネルに加わらないなら、SSM送付者がIPアドレスを変えることができませんか、または送付者は受信機に見え透いたIP移動性のテクニックを使用します。

2.6.2.  Hosts Receiving Multicast

2.6.2. マルチキャストを受けるホスト

   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

ホストはIGMP[RFC3376]とMLD[RFC3810]の使用でマルチキャストグループかチャンネルを受け取ることへの彼らの関心に合図します。 IGMPv2とMLDv1はまだ平凡ですが、また、新しい展開にしばしば使用されます。 いくつか

Savola                       Informational                     [Page 15]

RFC 5110               Multicast Routing Overview           January 2008

概要2008年1月に掘られるSavolaの情報[15ページ]のRFC5110マルチキャスト

   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/MLDバージョンを使用する受信機のためにテクニックを写像するSSMにどこをサポートするか、ルータが写像する、構成の様々で、通常複雑な手段に基づくSSMチャンネルに要求に参加してください。

2.6.3.  Summary

2.6.3. 概要

   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 |
   +--------------------+-------+------+----------------------------+

+-------+------+----------------------------+ | IPv4| IPv6| 注意| +--------------------+-------+------+----------------------------+ | ホスト発信| はい| はい| 必要でないサポート全く| | ホスト受信ASM| IGMP| MLD| どんなIGMP/MLDバージョン| | ホスト受信SSM| IGMPv3| MLDv2| SSM-マッピングがあるどんなバージョン| +--------------------+-------+------+----------------------------+

2.7.  Restricting Multicast Flooding in the Link Layer

2.7. リンクレイヤの中でマルチキャスト氾濫を制限します。

   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アドレスに基づいてフィルタリングをするなら、1つ以上のIPマルチキャストグループが同じMACアドレスに地図を扱うか、またはIGMPv3/MLDv2ソースフィルタが使用されているなら、ホストは不要なマルチキャストトラフィック(ホストのIP層の中で無視される)を受けるかもしれません。 受信者IPアドレスか、目的地とソースに基づいてアドレスをフィルターにかけるのは、これらを避けるのを助けますが、イーサネットフレームペイロードを構文解析に要求します。

   These options are discussed in this section.

このセクションでこれらのオプションについて議論します。

2.7.1.  Router-to-Router Flooding Reduction

2.7.1. ルータからルータへの氾濫減少

   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]は、交換網のルータの間の氾濫の量を減少させるために開発されました。 これは何らかのイーサネットベースのインターネットのExchangeポイントかVPNsの問題であると通常考えられるだけです。

Savola                       Informational                     [Page 16]

RFC 5110               Multicast Routing Overview           January 2008

概要2008年1月に掘られるSavolaの情報[16ページ]のRFC5110マルチキャスト

   There have been proposals to observe and possibly react ("snoop") PIM
   messages [PIM-SNOOP].

(「詮索好き」)PIMメッセージ[PIM-スヌープ]は、見るという提案であり、ことによると反応します。

2.7.2.  Host/Router Flooding Reduction

2.7.2. ホスト/ルータ氾濫減少

   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レポート抑圧のため、マルチキャストはまだリンクの上に少なくとも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仕様はGeneric Attribute Registrationプロトコル(ガープ)について説明します、そして、ガープMulticast Registrationプロトコル(GMRP)[GMRP]はMACマルチキャストグループ会員資格に関してスイッチに通知するガープのリンクレイヤマルチキャストグループアプリケーションです。 GMRPがIPマルチキャストに関連して使用されるなら、GMRP登録機能は「接合IGMP」に関連するようになるでしょう。 しかしながら、このGMRP-IGMP協会はGMRPの範囲を超えています。 GMRPはホストスタックで支持を要します、そして、それは広く実装されていません。 さらに、IEEE802.1は、IEEE 802.1ak[802.1ak]で指定されているMultiple Registrationプロトコル(MRP)とMulticast Multiple Registrationプロトコル(MMRP)に取り替えながら、ガープとGMRPが時代遅れであると考えます。 ブリッジの間でMMRPが主に使用されると予想されます。 また、ガープ/GMRPに関する何らかの詳細も[RFC3488]のAppendix 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詮索をサポートしないスイッチの上に詮索する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

また、詮索はパケットをあふれさせるようにルータがあるポートとしたがって、どこかを特定する必要性を切り換えます。 Multicast Routerディスカバリープロトコル[RFC4286]を使用することでこれを達成できます、あるIGMP質問[RFC4541]を見て、PIM Helloとことによると他のメッセージにおいて、または、手動の構成で見て。 問題

Savola                       Informational                     [Page 17]

RFC 5110               Multicast Routing Overview           January 2008

概要2008年1月に掘られるSavolaの情報[17ページ]のRFC5110マルチキャスト

   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-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 proxying[RFC4605]は小さいルータの上、または、集合IGMP/ MLDレポートへのマルチキャストルーティング・プロトコルの交換として詮索するIGMPと共に使用されると時々使用されます。

2.7.3.  Summary

2.7.3. 概要

   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 |
   +-----------------------+--------+-----+----------------------------+

+--------+-----+----------------------------+ | RからR| LAN| 注意| +-----------------------+--------+-----+----------------------------+ | シスコのRGMP| はい| いいえ| PIM詮索に取り替えます。| | PIM詮索| はい| いいえ| LANにおける安全保障問題| | IGMP/MLD詮索| いいえ| はい| 一般的であって、IGMPv3かMLDまれです。| | マルチキャストルータディスク| いいえ| はい| わずかしかいずれであるならもimplemされません。| | IEEE GMRPとMMRP| いいえ| いいえ| ホスト/ルータ展開がありません。| | シスコのCGMP| いいえ| はい| 詮索しながら、他に取り替えます。| +-----------------------+--------+-----+----------------------------+

3.  Acknowledgements

3. 承認

   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.

家庭教師aはマルチキャスト関連の書類を結合して、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、およびティム・ポークは良いコメントを提供しました、このドキュメントを改良するのを手伝って。

4.  IANA Considerations

4. IANA問題

   IANA has updated the following registries by adding a reference to
   this document:

IANAはこのドキュメントの参照を加えることによって、以下の登録をアップデートしました:

   o  OSPFv2 Options Registry: MC-bit

o OSPFv2オプション登録: ビットM.C.

   o  OSPFv2 Link State (LS) Type: Group-membership-LSA

o OSPFv2リンク州の(LS)はタイプします: 会員資格LSAを分類してください。

   o  OSPFv2 Router Properties Registry: W-bit

o OSPFv2ルータ特性の登録: W-ビット

Savola                       Informational                     [Page 18]

RFC 5110               Multicast Routing Overview           January 2008

概要2008年1月に掘られるSavolaの情報[18ページ]のRFC5110マルチキャスト

   o  OSPFv3 Options Registry: MC-bit

o OSPFv3オプション登録: ビットM.C.

   o  OSPFv3 LSA Function Code Registry: Group-membership-LSA

o OSPFv3 LSA機能コード登録: 会員資格LSAを分類してください。

   o  OSPFv3 Prefix Options Registry: MC-bit

o OSPFv3はオプション登録を前に置きます: ビットM.C.

5.  Security Considerations

5. セキュリティ問題

   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-THREATS]のセキュリティの分析がありました。

6.  References

6. 参照

6.1.  Normative References

6.1. 引用規格

   [RFC2026]       Bradner, S., "The Internet Standards Process --
                   Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、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インチ、RFC3376、2002年10月。」

   [RFC3618]       Fenner, B. and D. Meyer, "Multicast Source Discovery
                   Protocol (MSDP)", RFC 3618, October 2003.

[RFC3618]フェナーとB.とD.マイヤー、「マルチキャストソース発見プロトコル(MSDP)」、RFC3618 2003年10月。

   [RFC3810]       Vida, R. and L. Costa, "Multicast Listener Discovery
                   Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

そして、[RFC3810]ビーダ、R.、L.コスタ、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」

   [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.ハーバーマン、「ランデブーポイント(RP)を埋め込んで、IPv6でマルチキャストアドレスを扱ってください」、RFC3956、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):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。

   [RFC4607]       Holbrook, H. and B. Cain, "Source-Specific Multicast
                   for IP", RFC 4607, August 2006.

[RFC4607] ホルブルックとH.とB.カイン、「IPのためのソース特有のマルチキャスト」、RFC4607、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インチのためのMultiprotocol拡張子、RFC4760、2007年1月。」

Savola                       Informational                     [Page 19]

RFC 5110               Multicast Routing Overview           January 2008

概要2008年1月に掘られるSavolaの情報[19ページ]のRFC5110マルチキャスト

   [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.、Nguyen、L.、およびP.Pillay-Esnault、「OSPFのマルチトポロジー(MT)ルート設定」、RFC4915(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.、Speakman、T.、およびL.Vicisano、「双方向のプロトコル独立しているマルチキャスト(BIDIR-PIM)」、RFC5015、2007年10月。

6.2.  Informative References

6.2. 有益な参照

   [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/ページ/802.1ak.html>。

   [ADDRARCH]      Savola, P., "Overview of the Internet Multicast
                   Addressing Architecture", Work in Progress,
                   October 2006.

P.、「インターネットマルチキャストアドレッシング体系の概要」という[ADDRARCH]Savolaは進歩、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.

T.、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」という[DVMRPv3]Pusateriは進歩、2003年12月に働いています。

   [DVMRPv3-AS]    Pusateri, T., "Distance Vector Multicast Routing
                   Protocol Applicability Statement", Work in Progress,
                   May 2004.

[DVMRPv3、-、]、T.、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル適用性証明」というPusateriは進歩、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] レヒトネン、R.、Venaas、S.、およびM.Hoerdt、「ダイナミックなSSMソースの発見のための要件」、Progress、2005年2月のWork。

   [GMRP]          "GARP Multicast Registration Protocol",
                   <http://www.javvin.com/protocolGMRP.html>.

[GMRP]「ガープマルチキャスト登録プロトコル」、<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.

「IESG[吐き出される]のためのMBONED作業部会からのインターネットマルチキャストギャップ分析」という[不-ギャップ]のマイヤー、D.、およびB.Nicklessは進行中(2002年7月)で働いています。

   [IMRP-ISSUES]   Meyer, D., "Some Issues for an Inter-domain Multicast
                   Routing Protocol", Work in Progress, November 1997.

「相互ドメインマルチキャストルーティング・プロトコルのためのいくつかの問題」という[IMRP-問題]マイヤー、D.は進歩、1997年11月に働いています。

   [M-ISIS]        Przygienda, T., "M-ISIS: Multi Topology (MT) Routing
                   in IS-IS", Work in Progress, November 2007.

[Mイシス]Przygienda、T.、「Mイシス:」 「中のマルチトポロジー(MT)ルート設定、-、」、11月2007、進行中で、働いてください。

   [MCAST-ISSUES]  Savola, P., "IPv6 Multicast Deployment Issues", Work
                   in Progress, February 2005.

「IPv6マルチキャスト展開問題」という[MCAST-問題]Savola、P.は進歩、2005年2月に働いています。

Savola                       Informational                     [Page 20]

RFC 5110               Multicast Routing Overview           January 2008

概要2008年1月に掘られるSavolaの情報[20ページ]のRFC5110マルチキャスト

   [MLD-SEC]       Daley, G. and G. Kurup, "Trust Models and Security in
                   Multicast Listener Discovery", Work in Progress,
                   July 2004.

「マルチキャストリスナー発見における信頼モデルとセキュリティ」という[MLD-SEC]のデイリー、G.、およびG.クルップは進歩、2004年7月に働いています。

   [PIM-SNOOP]     Hemige, V., "PIM Snooping over VPLS", Work
                   in Progress, March 2007.

V.、「VPLSの上で詮索するPIM」という[PIM-スヌープ]Hemigeは進歩、2007年3月に働いています。

   [PIM-THREATS]   Savola, P. and J. Lingard, "Host Threats to Protocol
                   Independent Multicast (PIM)", Work in Progress,
                   October 2007.

[PIM-脅威] 「独立しているマルチキャスト(PIM)について議定書の中で述べるホストの脅威」というSavola、P.、およびJ.リンガードは進歩、2007年10月に働いています。

   [RFC1075]       Waitzman, D., Partridge, C., and S. Deering,
                   "Distance Vector Multicast Routing Protocol",
                   RFC 1075, November 1988.

[RFC1075] WaitzmanとD.とヤマウズラ、C.とS.デアリング、「ディスタンス・ベクタ・マルチキャスト・ルーティング・プロトコル」、RFC1075、1988年11月。

   [RFC1112]       Deering, S., "Host extensions for IP multicasting",
                   STD 5, RFC 1112, August 1989.

[RFC1112] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。

   [RFC1458]       Braudes, B. and S. Zabele, "Requirements for
                   Multicast Protocols", RFC 1458, May 1993.

[RFC1458] Braudes、B.、およびS.Zabele(「マルチキャストプロトコルのための要件」、RFC1458)は1993がそうするかもしれません。

   [RFC1584]       Moy, J., "Multicast Extensions to OSPF", RFC 1584,
                   March 1994.

[RFC1584] Moy、J.、「OSPFへのマルチキャスト拡大」、RFC1584、1994年3月。

   [RFC2189]       Ballardie, T., "Core Based Trees (CBT version 2)
                   Multicast Routing -- Protocol Specification --",
                   RFC 2189, September 1997.

[RFC2189]Ballardie、T.、「コアBased Trees(CBTバージョン2)マルチキャストルート設定(プロトコルSpecification)」、RFC2189、1997年9月。

   [RFC2201]       Ballardie, T., "Core Based Trees (CBT) Multicast
                   Routing Architecture", RFC 2201, September 1997.

[RFC2201] Ballardie、T.、「コアのベースの木(CBT)のマルチキャストルート設定アーキテクチャ」、RFC2201、1997年9月。

   [RFC2715]       Thaler, D., "Interoperability Rules for Multicast
                   Routing Protocols", RFC 2715, October 1999.

[RFC2715] ターレル、D.、「マルチキャストルーティング・プロトコルのための相互運用性規則」、RFC2715、1999年10月。

   [RFC2784]       Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
                   Traina, "Generic Routing Encapsulation (GRE)",
                   RFC 2784, March 2000.

2000年3月の[RFC2784]ファリナッチとD.と李とT.とハンクスとS.とマイヤー、D.とP.Traina、「一般ルーティングのカプセル化(GRE)」RFC2784。

   [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.、クロウクロフト、J.、Gemmell、J.、ファリナッチ、D.、リン、S.、Leshchiner、D.、Luby、M.、モンゴメリ、T.、リゾー、L.、Tweedly、A.、Bhaskar、N.、Edmonstone、R.、Sumanasekera、R.、およびL.Vicisano、「PGMの信頼できる輸送プロトコル仕様」、RFC3208(2001年12月)。

Savola                       Informational                     [Page 21]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[21ページ]のRFC5110マルチキャスト

   [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.ファリナッチ、「プロトコルの無党派Multicast(PIM)とMulticast Sourceディスカバリープロトコル(MSDP)を使用するAnycast Rendevous Point(RP)メカニズム」、RFC3446(2003年1月)。

   [RFC3488]       Wu, I. and T. Eckert, "Cisco Systems Router-port
                   Group Management Protocol (RGMP)", RFC 3488,
                   February 2003.

[RFC3488] ウーとI.とT.エッケルト、「シスコシステムズルータポートグループ管理プロトコル(RGMP)」、RFC3488、2003年2月。

   [RFC3740]       Hardjono, T. and B. Weis, "The Multicast Group
                   Security Architecture", RFC 3740, March 2004.

[RFC3740] HardjonoとT.とB.ウィス、「マルチキャストグループセキュリティー体系」、RFC3740、2004年3月。

   [RFC3913]       Thaler, D., "Border Gateway Multicast Protocol
                   (BGMP): Protocol Specification", RFC 3913,
                   September 2004.

[RFC3913] ターレル、D.、「境界ゲートウェイマルチキャストは以下について議定書の中で述べ(BGMP)」。 「プロトコル仕様」、RFC3913、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):、」 「プロトコル仕様(改訂される)」、RFC3973、2005年1月。

   [RFC4286]       Haberman, B. and J. Martin, "Multicast Router
                   Discovery", RFC 4286, December 2005.

[RFC4286] ハーバーマンとB.とJ.マーチン、「マルチキャストルータ発見」、RFC4286、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、「スイッチについて詮索して、インターネット集団経営のための問題は(IGMP)とマルチキャストリスナー発見(MLD)について議定書の中で述べます」、RFC4541、2006年5月。

   [RFC4566]       Handley, M., Jacobson, V., and C. Perkins, "SDP:
                   Session Description Protocol", RFC 4566, July 2006.

[RFC4566] ハンドレー、M.、ジェーコブソン、V.、およびC.パーキンス、「SDP:」 「セッション記述プロトコル」、RFC4566、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 Proxying")について議定書の中で述べます」、RFC4605、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.、レヒトネン、R.、およびD.マイヤー、「独立しているマルチキャストについて議定書の中で述べてください--まばらなモード(PIM-Sm)マルチキャストルート設定安全保障問題と増進」、RFC4609、2006年10月。

   [RFC4610]       Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol
                   Independent Multicast (PIM)", RFC 4610, August 2006.

[RFC4610]ファリナッチとD.とY.Cai、「プロトコルの独立しているマルチキャスト(PIM)を使用するAnycast-RP」、RFC4610、2006年8月。

Savola                       Informational                     [Page 22]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[22ページ]のRFC5110マルチキャスト

   [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)メカニズムを独力で進みます」、RFC5059、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/>.

K. [RITVANEN]Ritvanen、「マルチキャストは、発送して、記述すること」でのHUT Report、Internetworking、2004年5月、<http://www.tml.hut.fi/Studies/T-110.551/2004/ papers/>の上のSeminar。

Savola                       Informational                     [Page 23]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[23ページ]のRFC5110マルチキャスト

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.

2、3のメカニズムが、マルチキャストの上で輸送できるデータの特性を改良するために指定されました。

   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.

メカニズムの大部分はホストベースです、そして、そういうものとして、このドキュメントの範囲から、マルチキャストルーティング見解から関連している唯一の1つはPragmatic Generic Multicast(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]を使用することでSecurity作業部会がデータの保全、秘密性、および認証がマルチキャストグループに発信した方法を扱っているマルチキャストを確実にすることができます。

Author's Address

作者のアドレス

   Pekka Savola
   CSC - Scientific Computing Ltd.
   Espoo
   Finland

ペッカSavola CSC--科学計算株式会社エスポーフィンランド

   EMail: psavola@funet.fi

メール: psavola@funet.fi

Savola                       Informational                     [Page 24]

RFC 5110               Multicast Routing Overview           January 2008

概観2008年1月に掘られるSavolaの情報[24ページ]のRFC5110マルチキャスト

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2008).

IETFが信じる著作権(C)(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Savola                       Informational                     [Page 25]

Savola情報です。[25ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

初期に作成されるデータベーステーブル

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る