Network Working Group S. Bhattacharyya, Ed.
Request for Comments: 3569 Sprint
Category: Informational July 2003
An Overview of Source-Specific Multicast (SSM)
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
The purpose of this document is to provide an overview of Source-Specific Multicast (SSM) and issues related to its deployment. It discusses how the SSM service model addresses the challenges faced in inter-domain multicast deployment, changes needed to routing protocols and applications to deploy SSM and interoperability issues with current multicast service models.
このドキュメントの目的は、ソース固有のマルチキャスト（SSM）とその展開に関連する問題の概要を提供することです。これは、SSMサービスモデルは、ドメイン間のマルチキャストの展開に直面している課題、現在のマルチキャストサービスモデルとSSMおよび相互運用性の問題を展開するルーティングプロトコルおよびアプリケーションに必要な変更を対処方法について説明します。
This document provides an overview of the Source-Specific Multicast (SSM) service and its deployment using the PIM-SM and IGMP/MLD protocols. The network layer service provided by SSM is a "channel", identified by an SSM destination IP address (G) and a source IP address S. An IPv4 address range has been reserved by IANA for use by the SSM service. An SSM destination address range already exists for IPv6. A source S transmits IP datagrams to an SSM destination address G. A receiver can receive these datagrams by subscribing to the channel (Source, Group) or (S,G). Channel subscription is supported by version 3 of the IGMP protocol for IPv4 and version2 of the MLD protocol for IPv6. The interdomain tree for forwarding IP multicast datagrams is rooted at the source S, and is constructed using the PIM Sparse Mode [9] protocol.
この文書では、PIM-SMとIGMP / MLDプロトコルを使用してソース固有マルチキャスト（SSM）サービスとその展開の概要を説明します。 SSMによって提供されるネットワーク層サービスは、SSM宛先IPアドレス（G）及びS.アンIPv4アドレス範囲は、SSMサービスによる使用のためにIANAによって予約された送信元IPアドレスによって識別される「チャネル」です。 SSM宛先アドレスの範囲は、すでにIPv6のために存在します。ソースSは、チャネル（ソース、グループ）または（S、G）に加入することにより、これらのデータグラムを受信することができるSSM宛先アドレスG. A受信機にIPデータグラムを送信します。チャンネルサブスクリプションは、IPv6のMLDプロトコルのIPv4のIGMPプロトコルのバージョン3およびバージョン2でサポートされています。 IPマルチキャストデータグラムを転送するためのドメイン間ツリーは、ソースSをルートとし、PIMスパースモード[9]プロトコルを用いて構築されています。
This document is not intended to be a standard for Source-Specific Multicast (SSM). Instead, its goal is to serve as an introduction to SSM and its benefits for anyone interested in deploying SSM services. It provides an overview of SSM and how it solves a number of problems faced in the deployment of inter-domain multicast. It outlines changes to protocols and applications both at end-hosts and routers for supporting SSM, with pointers to more detailed documents where appropriate. Issues of interoperability with the multicast service model defined by RFC 1112 are also discussed.
この文書は、ソース固有のマルチキャスト（SSM）のための標準であることを意図したものではありません。代わりに、その目標は、SSMサービスを展開に興味がある人のためのSSMとその利点を紹介として機能することです。これは、SSMの概要を提供し、それは、ドメイン間のマルチキャストの展開に直面する多くの問題を解決する方法。これは、ポインタへのより詳細なドキュメント適切で、SSMをサポートするためのエンドホストとルータの両方のプロトコルやアプリケーションへの変更を概説します。 RFC 1112で定義されたマルチキャストサービスモデルとの相互運用性の問題も議論されています。
This memo is a product of the Source-Specific Multicast (SSM) Working Group of the Internet Engineering Task Force.
このメモはインターネットエンジニアリングタスクフォースのソース固有マルチキャスト（SSM）ワーキンググループの製品です。
The keywords "MUST"", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as defined in BCP 14, RFC 2119 [28].
キーワードは「、この文書では、 "REQUIRED" "NOT MUST"、 "べきではない" "べきである" "ないもの"、 "推奨" "ものとし"、 "MAY"、および "オプション" されている "MUST" BCP 14で定義されるように解釈されるためには、RFC 2119 [28]。
This section defines some terms that are used in the rest of this document:
このセクションでは、このドキュメントの残りの部分で使用されているいくつかの用語を定義しています。
Any-Source Multicast (ASM): This is the IP multicast service model defined in RFC 1112 [25]. An IP datagram is transmitted to a "host group", a set of zero or more end-hosts (or routers) identified by a single IP destination address (224.0.0.0 through 239.255.255.255 for IPv4). End-hosts may join and leave the group any time, and there is no restriction on their location or number. Moreover, this model supports multicast groups with arbitrarily many senders - any end-host (or router) may transmit to a host group, even if it is not a member of that group.
どれ-ソースマルチキャスト（ASM）：これは、[25] RFC 1112で定義されたIPマルチキャストサービスモデルです。 IPデータグラムは、「ホストグループ」は、単一のIP宛先アドレス（IPv4の239.255.255.255を介して224.0.0.0）によって識別されるゼロ個以上のエンドホスト（またはルータ）の組に送信されます。エンドホストが参加してグループを去るいつでも、その場所や数に制限は存在しなくてもよいです。また、このモデルは、任意の数の送信者とのマルチキャストグループをサポート - 任意のエンドホスト（またはルータ）は、それがそのグループのメンバーでない場合でも、ホストグループに送信してもよいです。
Source-Specific Multicast (SSM): This is the multicast service model defined in [5]. An IP datagram is transmitted by a source S to an SSM destination address G, and receivers can receive this datagram by subscribing to channel (S,G). SSM provides host applications with a "channel" abstraction, in which each channel has exactly one source and any number of receivers. SSM is derived from earlier work in EXPRESS [1]. The address range 232/8 has been assigned by IANA for SSM service in IPv4. For IPv6, the range FF3x::/96 is defined for SSM services [21].
ソース固有マルチキャスト（SSM）：これは、[5]で定義されたマルチキャストサービスモデルです。 IPデータグラムは、SSM宛先アドレスGにソースSによって送信され、受信機は（S、G）をチャンネルに加入することによって、このデータグラムを受信することができます。 SSMは、各チャネルは、ちょうど1つのソースと受信機の任意の数を有する、「チャネル」抽象化とホストアプリケーションを提供します。 SSMは、EXPRESSで以前の仕事に由来する[1]。アドレス範囲232/8は、IPv4のSSMサービスのためにIANAによって割り当てられています。 IPv6の場合、範囲FF3x :: / 96は、SSMサービス[21]のために定義されています。
Source-Filtered Multicast (SFM): This is a variant of the ASM service model, and uses the same address range as ASM (224.0.0.0-239.255.255.255). It extends the ASM service model as follows. Each "upper layer protocol module" can now request data sent to a host group G by only a specific set of sources, or can request data sent to host group G from all BUT a specific set of sources. Support for source filtering is provided by version 3 of the Internet Group Management Protocol (or IGMPv3) [3] for IPv4, and version 2 of the Multicast Listener Discovery (or MLDv2) [22] protocol for IPv6. We shall henceforth refer to these two protocols as "SFM-capable". Earlier versions of these protocols - IGMPv1/IGMPv2 and MLDv1 - do not provide support for source-filtering, and are referred to as "non-SFM-capable". Note that while SFM is a different model than ASM from a receiver standpoint, there is no distinction between the two for a sender.
ソース濾過マルチキャスト（SFM）：これはASMサービスモデルの変形であり、ASM（224.0.0.0-239.255.255.255）と同じアドレス範囲を使用しています。これは次のようにASMサービスモデルを拡張します。各「上位層プロトコル・モジュールは、」今のソースのみ特定のセットによってホストグループGに送信されるデータを要求することができる、またはすべてのBUT源の特定のセットからグループGをホストに送信データを要求することができます。ソースフィルタのサポートは、インターネットグループ管理プロトコル（またはIGMPv3の）[3] IPv4の、マルチキャストリスナー発見（またはのMLDv2）のバージョン2 IPv6の[22]プロトコルのバージョン3が提供されます。私たちは今後、「SFM-できる」として、これらの2つのプロトコルを指すものとします。 IGMPv1 / IGMPv2のとのMLDv1 - - これらのプロトコルの以前のバージョンでは、ソース・フィルタリングのためのサポートを提供していない、と「非SFM-できる」と呼ばれています。 SFMは、受信機の観点からASMとは異なるモデルでありながら、送信のための2つの間には違いがないことに留意されたいです。
For the purpose of this document, we treat the scoped multicast model of [12] to be a variant of ASM since it does not explicitly restrict the number of sources, but only requires that they be located within the scope zone of the group.
このドキュメントの目的のために、我々はそれが明示的にソースの数を制限していないため、ASMの変種であることを、[12]のスコープのマルチキャストモデルを扱うが、唯一の彼らはグループのスコープゾーン内に位置されている必要があります。
As of this writing, all multicast-capable networks support the ASM service model. One of the most common multicast protocol suites for supporting ASM consists of IGMP version 2 [2], PIM-SM [8,9], MSDP [13] and MBGP [26]. IGMPv2 is the most commonly used protocol for hosts to specify membership in a multicast group, and nearly all multicast routers support (at least) IGMPv2. In case of IPv6, MLDv1 [21] is the commonly used protocol.
この記事の執筆時点で、すべてのマルチキャスト対応ネットワークは、ASMサービスモデルをサポートしています。 ASMを支持するための最も一般的なマルチキャストプロトコルスイートの一つは、IGMPバージョン2で構成され[2]、PIM-SM [8,9]、MSDP [13]とMBGP [26]。ホストがマルチキャストグループのメンバーシップを指定し、ほぼすべてのマルチキャストルータサポート（少なくとも）のIGMPv2するIGMPv2のは、最も一般的に使用されるプロトコルです。 IPv6の、のMLDv1 [21]の場合に一般的に使用されるプロトコルです。
Although a number of protocols such as PIM-DM [10], CBT [24,11], DVMRP [6], etc. exist for building multicast tree among all receivers and sources in the same administrative domain, PIM-SM [8,9] is the most widely used protocol. PIM-SM builds a spanning multicast tree rooted at a core rendezvous point or RP for all group members within a single administrative domain. A 'first-hop' router adjacent to a multicast source sends the source's traffic to the RP for its domain. The RP forwards the data down the shared spanning tree to all interested receivers within the domain. PIM-SM also allows receivers to switch to a source-based shortest path tree.
[10]そのようなPIM-DMなどのプロトコルの数が、CBT [24,11]、DVMRP [6]など、8 [同じ管理ドメイン、PIM-SM内のすべての受信機とソースの間でマルチキャストツリーを構築するために存在します9】最も広く使用されるプロトコルです。 PIM-SMは、単一の管理ドメイン内のすべてのグループメンバーのコアランデブーポイントまたはRPをルートとスパニングマルチキャストツリーを構築します。マルチキャストソースに隣接した「最初のホップ」ルーターはそのドメインのRPにソースのトラフィックを送信します。 RPは、ドメイン内のすべての興味を持って受信者に共有スパニングツリーの下にデータを転送します。 PIM-SMはまた、受信機は、ソースベースの最短経路ツリーに切り替えることができます。
As of this writing, multicast end-hosts with SFM capabilities are not widely available. Hence a client can only specify interest in an entire host group and receives data sent from any source to this group.
この記事の執筆時点で、SFM機能を持つマルチキャストエンドホストは、広く利用可能ではありません。したがって、クライアントは、全体のホストグループへの関心を指定し、このグループに任意のソースから送信されたデータを受信することができます。
Inter-domain multicast service (i.e., where sources and receivers are located in different domains) requires additional protocols - MSDP [13] and MBGP [26] are the most commonly used ones. An RP uses the MSDP protocol to announce multicast sources to RPs in other domains. When an RP discovers a source in a different domain transmitting data to a multicast group for which there are interested receivers in its own domain, it joins the shortest-path source based tree rooted at that source. It then redistributes the data received to all interested receivers via the intra-domain shared tree rooted at itself.
（すなわち、ソース及び受信機は異なるドメインに配置されている）ドメイン間マルチキャストサービスは追加のプロトコルが必要 - MSDP [13]とMBGP [26]最も一般的に使用されるものです。 RPは、他のドメインのRPにマルチキャストソースを発表するMSDPプロトコルを使用しています。 RP興味受信機は、自身のドメイン内に存在しているマルチキャストグループにデータを送信する別のドメイン内のソースを検出すると、そのソースをルート最短パスソースベースのツリーを結合します。その後、自分自身をルートドメイン内の共有ツリーを介し関心を持つすべての受信者に、受信したデータを再分配します。
MBGP defines extensions to the BGP protocol to support the advertisement of reachability information for multicast routes. This allows an autonomous system (AS) to support incongruent unicast and multicast routing topologies, and thus implement separate routing policies for each.
MBGPは、マルチキャストルートの到達可能性情報の広告をサポートするためにBGPプロトコルに拡張を定義します。これは、不適合ユニキャストおよびマルチキャストルーティングトポロジをサポートし、したがって、それぞれ個別のルーティングポリシーを実装するための自律システム（AS）を可能にします。
However, the last-hop routers of interested receivers may eventually switch to a shortest-path tree rooted at the source that is transmitting the data.
しかし、興味の受信機の最後のホップルータは、最終的にデータを送信しているソースをルートとする最短経路ツリーに切り替えることができます。
There are several deployment problems associated with current multicast architecture:
現在のマルチキャストアーキテクチャに関連するいくつかの展開の問題があります。
A) Address Allocation:
A）アドレスの割り当て：
Address allocation is one of core deployment challenges posed by the ASM service model. The current multicast architecture does not provide a deployable solution to prevent address collisions among multiple applications. The problem is much less serious for IPv6 than for IPv4 since the size of the multicast address space is much larger. A static address allocation scheme, GLOP [17] has been proposed as an interim solution for IPv4; however, GLOP addresses are allocated per registered AS, which is inadequate in cases where the number of sources exceeds the AS numbers available for mapping. RFC 3138 expands on RFC 2770 to allow routing registries to assign multicast addresses from the GLOP space corresponding to the RFC 1930 private AS space [27]. This space is referred to as the EGLOP (Extended GLOP) address space. Proposed longer-term solutions such as the Multicast Address Allocation Architecture [14] are generally perceived as being too complex (with respect to the dynamic nature of multicast address allocation) for widespread deployment.
アドレス割り当てはASMサービスモデルによってもたらされるコアの展開の課題の一つです。現在のマルチキャストアーキテクチャでは、複数のアプリケーション間でアドレス衝突を防ぐために展開可能なソリューションを提供していません。マルチキャストアドレス空間のサイズが非常に大きいので問題はそれほど深刻なのIPv4よりもIPv6のです。静的アドレス割り当て方式、GLOP [17] IPv4の暫定的な解決策として提案されています。しかし、GLOPアドレスは源の数は、マッピングのために使用可能なAS番号を超える場合には不適当である登録され、当たり割り当てられます。 RFC 3138は、ルーティングレジストリはスペース[27] ASプライベートRFC 1930に対応したGLOP空間からマルチキャストアドレスを割り当てることができるように、RFC 2770を拡張したものです。このスペースはEGLOP（拡張GLOP）アドレス空間と呼ぶことにします。そのようなマルチキャストアドレス配分アーキテクチャとして提案されている長期的なソリューション[14]一般に広範囲の展開のために（マルチキャストアドレス割り当ての動的な性質に関して）あまりにも複雑であると知覚されます。
B) Lack of Access control:
B）アクセス制御の欠如：
In the ASM service model, a receiver cannot specify which specific sources it would like to receive when it joins a given group. A receiver will be forwarded data sent to a host group by any source. Moreover, even when a source is allocated a multicast group address to transmit on, it has no way of enforcing that no other source will use the same address. This is true even in the case of IPv6, where address collisions are less likely due to the much larger size of the address space.
ASMサービスモデルでは、受信機は、それが与えられたグループに参加するときに受信したい特定のどのソースを指定することができません。受信機は、任意の供給源によってホストグループに送信されたデータを転送します。また、ソースは、上で送信するマルチキャストグループアドレスを割り当てた場合であっても、他のソースが同じアドレスを使用しないことを強制する方法がありません。これは、偶数アドレスの衝突が原因のアドレス空間のはるかに大きいサイズに可能性が低いのIPv6の場合に当てはまります。
C) Inefficient handling of well-known sources:
よく知られているソースのC）非効率的な処理：
In cases where the address of the source is well known in advance of the receiver joining the group, and when the shortest forwarding path is the preferred forwarding mode, then shared tree mechanisms are not necessary.
送信元のアドレスが良好にグループに参加する受信機、及び場合最短転送経路が好ましい転送モードでの予め分かっている場合には、その後、共有ツリー機構は不要です。
As mentioned before, the Source Specific Multicast (SSM) service model defines a "channel" identified by an (S,G) pair, where S is a source address and G is an SSM destination address. Channel subscriptions are described using an SFM-capable group management protocol such as IGMPv3 or MLDv2. Only source-based forwarding trees are needed to implement this model.
前に述べたように、ソース固有マルチキャスト（SSM）サービスモデルは、Sがソース・アドレスであり、Gは、SSM宛先アドレスである（S、G）ペアによって識別「チャネル」を定義します。チャネル・サブスクリプションは、IGMPv3のまたはMLDv2のようSFM-可能なグループ管理プロトコルを使用して記載されています。唯一のソースベースの転送木はこのモデルを実装するために必要な。
The SSM service model alleviates all of the deployment problems described earlier:
SSMサービスモデルは、前述の展開の問題のすべてを軽減します：
A) Address Allocation: SSM defines channels on a per-source basis, i.e., the channel (S1,G) is distinct from the channel (S2,G), where S1 and S2 are source addresses, and G is an SSM destination address. This averts the problem of global allocation of SSM destination addresses, and makes each source independently responsible for resolving address collisions for the various channels that it creates.
A）アドレスの割り当て：SSM、すなわち、毎ソースに基づいてチャネルを定義S1及びS2は、ソースアドレスであり、Gは、SSM宛先アドレスであり、チャネル（S1、G）は、チャネル（S2、G）とは区別されます。これは、SSM宛先アドレスのグローバル割り当ての問題をaverts、およびそれが作成する様々なチャネルのアドレス衝突を解決するために、各ソースは独立して責任を負うことができます。
B) Access Control: SSM lends itself to an elegant solution to the access control problem. When a receiver subscribes to an (S,G) channel, it receives data sent only by the source S. In contrast, any host can transmit to an ASM host group. At the same time, when a sender picks a channel (S,G) to transmit on, it is automatically ensured that no other sender will be transmitting on the same channel (except in the case of malicious acts such as address spoofing). This makes it much harder to "spam" an SSM channel than an ASM multicast group.
B）アクセス制御：SSMは、アクセス制御問題にエレガントな解決策に役立ちます。受信機は（S、G）チャネルに加入したとき、それは対照的にのみソースSによって送信されたデータを受信し、すべてのホストは、ASMホストグループに送信することができます。送信側が上で送信するためのチャネル（S、G）を選ぶと同時に、自動的に他の送信者が（例えば、アドレススプーフィングなどの悪意のある行為の場合を除いて）同じチャネル上で送信しないことを保証されます。これは、「スパム」ASMマルチキャストグループよりもSSMチャネルに、それははるかに困難になります。
C) Handling of well-known sources: SSM requires only source-based forwarding trees; this eliminates the need for a shared tree infrastructure. This implies that neither the RP-based shared tree infrastructure of PIM-SM nor the MSDP protocol is required. Thus the complexity of the multicast routing infrastructure for SSM is low, making it viable for immediate deployment. Note that there is no difference in how MBGP is used for ASM and SSM.
よく知られているソースのC）取り扱い：SSMは、ソースベースの転送ツリーを必要とします。これは、共有ツリーのインフラが不要になります。これは、PIM-SMのRPベースの共有ツリーのインフラもMSDPプロトコルのいずれも必要であることを意味します。従って、SSMのマルチキャストルーティングインフラストラクチャの複雑さは、即時展開のため、それが実行可能な作り、低いです。 MBGPは、ASMとSSMのために使用される方法に差がないことに注意してください。
Figure 1 illustrates the elements in an end-to-end implementation framework for SSM:
図1は、SSMのエンドツーエンドの実装フレームワークの要素を示しています。
--------------------------------------------------------------
IANA assigned 232/8 for IPv4 ADDRESS ALLOCATION
FF3x::/96 for IPv6
--------------------------------------------------------------
|
v
+--------------+ session directory/web page
| source,group | SESSION DESCRIPTION
--------------------------------------------------------------
^ |
Query | | (S,G)
| v
+-----------------+ host
| SSM-aware app | CHANNEL DISCOVERY
--------------------------------------------------------------
| SSM-aware app | SSM-AWARE APPLICATION
--------------------------------------------------------------
| IGMPv3/MLDv2 | IGMPv3/MLDv2 HOST REPORTING
+-----------------+
|(source specific host report)
--------------------------------------------------------------
v
+-----------------+ Querier Router
| IGMPv3/MLDv2 | QUERIER
--------------------------------------------------------------
| PIM-SSM | PIM-SSM ROUTING
+------------+ Designated Router
|
| (S,G) Join only
v
+-----------+ Backbone Router
| PIM-SSM |
+-----------+
|
| (S,G) Join only
V
Figure 1: SSM Framework: elements in end-to-end model
図1：SSMフレームワーク：エンドツーエンドモデルの要素
We now discuss the framework elements in detail:
私たちは今、詳細にフレームワークの要素について説明します。
For IPv4, the address range of 232/8 has been assigned by IANA for SSM. To ensure global SSM functionality in 232/8, including in networks where routers run non-SFM-capable protocols, operational policies are being proposed [9] which recommend that routers should not send SSM traffic to parts of the network that do not have channel subscribers.
IPv4の場合、232/8のアドレス範囲は、SSMのためにIANAによって割り当てられています。ルータが非SFM対応のプロトコルを実行するネットワークに含め、232/8でグローバルSSM機能を確保するために、運用ポリシーが提案されている[9]ルータがチャネルを持っていないネットワークの部分にSSMトラフィックを送信しないことをお勧めしています加入。
Note that IGMPv3/MLDv2 does not limit (S,G) joins to only the 232/8 range. However, SSM service, as defined in [5], is available only in this address range for IPv4.
IGMPv3 / MLDv2のは（S、G）は唯一232/8の範囲に加入限定するものではないことに留意されたいです。しかし、SSMサービスは、[5]で定義されるように、IPv4のみのために、このアドレス範囲で使用可能です。
In case of IPv6, [23] has defined an extension to the addressing architecture to allow for unicast prefix-based multicast addresses. See RFC 3306 for details.
IPv6の、[23]の場合にユニキャストプレフィックスベースのマルチキャストアドレスを可能にするためにアドレス指定アーキテクチャに拡張を定義しています。詳細については、RFC 3306を参照してください。
An SSM receiver application must know both the SSM destination address G and the source address S before subscribing to a channel. Channel discovery is the responsibility of applications. This information can be made available in a number of ways, including via web pages, sessions announcement applications, etc. This is similar to what is used for ASM applications where a multicast session needs to be announced so that potential subscribers can know of the multicast group address, encoding schemes used, etc. In fact, the only additional piece of information that needs to be announced is the source address for the channel being advertised. However, the exact mechanisms for doing this is outside the scope of this framework document.
SSMレシーバアプリケーションは、チャネルに加入する前に、SSM宛先アドレスGとソースアドレスSの両方を知っていなければなりません。チャネルの発見は、アプリケーションの責任です。この情報は、潜在的な加入者がマルチキャストを知ることができるように、これは、マルチキャストセッションが発表される必要があるASMのアプリケーションに使用されているものに似ているなど、Webページ経由を含め、いくつかの方法でセッションの発表・アプリケーションを使用可能にすることができます等のグループアドレス、使用される符号化方式、実際には、発表される必要がある情報の唯一の追加部分は、広告されているチャネルの送信元アドレスです。しかし、これを行うための正確なメカニズムは、このフレームワーク文書の範囲外です。
There are two main issues in making multicast applications "SSM-aware":
「SSM対応の」マルチキャストアプリケーションを作る2つの主要な問題があります。
- An application that wants to receive an SSM session must first discover the channel address in use.
- SSMのセッションを受信したいアプリケーションが最初に使用中のチャンネルのアドレスを検出する必要があります。
- A receiving application must be able to specify both a source address and a destination address to the network layer protocol module on the end-host.
- 受信アプリケーションは、エンドホスト上のネットワーク層プロトコル・モジュールに送信元アドレスおよび宛先アドレスの両方を指定することができなければなりません。
Specific API requirements are identified in [16]. [16] describes a recommended application programming interface for a host operating system to support the SFM service model. Although it is intended for SFM, a subset of this interface is sufficient for supporting SSM.
特定のAPIの要件は、[16]で識別されています。 [16] SFMサービスモデルをサポートするために、ホストオペレーティングシステムに推奨アプリケーション・プログラミング・インターフェースを記述する。それはSFMのために意図されているが、このインターフェースのサブセットは、SSMをサポートするために十分です。
In order to use SSM service, an end-host must be able to specify a channel address, consisting of a source's unicast address and an SSM destination address. IGMP version 2 [3] and MLD version 1 [19] allows an end-host to specify only a destination multicast address. The ability to specify an SSM channel address c is provided by IGMP version 3 [3] and MLD version 2 [20]. These protocols support "source filtering", i.e., the ability of an end-system to express interest in receiving data packets sent only by SPECIFIC sources, or from ALL BUT some specific sources. In fact, IGMPv3 provides a superset of the capabilities required to realize the SSM service model.
SSMサービスを利用するために、エンドホストが元のユニキャストアドレスとSSM宛先アドレスからなる、チャネルアドレスを指定することができなければなりません。 IGMPバージョン2 [3]とMLDバージョン1 [19]エンドホストのみ宛先マルチキャストアドレスを指定することを可能にします。 SSMチャネルアドレスCを指定する機能は、IGMPバージョン3 [3]、MLDバージョン2 [20]によって提供されます。これらのプロトコルは、「ソースフィルタリング」、サポートすなわち、のみ、または全てから特定のソースが、いくつかの特定のソースによって送信されたデータパケットを受信することに関心を表現するエンドシステムの能力。実際には、IGMPv3がSSMサービスモデルを実現するために必要な機能のスーパーセットを提供します。
A detailed discussion of the use of IGMPv3 in the SSM destination address range is provided in [4].
SSM宛先アドレス範囲内のIGMPv3の使用の詳細な議論は、[4]に設けられています。
The Multicast Listener Discovery (MLD) protocol used by an IPv6 router to discover the presence of multicast listeners on its directly attached links, and to discover the multicast addresses that are of interest to those neighboring nodes. MLD version 1 is derived from IGMPv2 and does not provide the source filtering capability required for the SSM service model. MLD version 2 is derived from, and provides the same support for source-filtering as, IGMPv3. Thus IGMPv3 (or MLDv2 for IPv6) provides a host with the ability to request the network for an SSM channel subscription.
IPv6ルータによって使用Multicast Listener Discovery（MLD）プロトコルは、直接接続されたリンク上のマルチキャストリスナーの存在を発見し、それらの隣接ノードに関心のあるマルチキャスト・アドレスを発見します。 MLDバージョン1は、IGMPv2に由来し、SSMサービスモデルのために必要なソースフィルタリング機能を提供しません。 MLDバージョン2に由来する、およびIGMPv3などのソースフィルタリングのために同一のサポートを提供しています。こうしてのIGMPv3（またはIPv6用のMLDv2）は、SSMチャネルサブスクリプションのためにネットワークに要求する能力をホストに提供します。
[9] provides guidelines for how a PIM-SM implementation should handle source-specific host reports as required by SSM. Earlier versions of the PIM protocol specifications did not describe how to do this.
[9] PIM-SMの実装は、SSMで必要とされるソース固有のホストレポートを処理する方法についてのガイドラインを提供します。 PIMプロトコル仕様の以前のバージョンでは、これを実行する方法については説明しませんでした。
The router requirements for operation in the SSM range are detailed in [5]. These rules are primarily concerned with preventing ASM-style behaviour in the SSM address range. In order to comply with [5] several changes to the PIM-SM protocol are required, as described in [9]. The most important changes in PIM-SM required for compliance with [5] are:
SSM範囲での動作のためのルータ要件は、[5]に詳述されています。これらのルールは、SSMアドレス範囲でASM-スタイルの動作を防止して、主に懸念しています。 [9]に記載されているように準拠するために、[5] PIM-SMプロトコルにいくつかの変更が必要です。準拠するために必要なPIM-SMの中で最も重要な変更は、[5]、次のとおりです。
- When a DR receives an (S,G) join request with the address G in the SSM address range, it MUST initiate a (S,G) join, and NEVER a (*,G) join.
- DRは（S、G）はSSMアドレス範囲内のアドレスGと参加要求を受信すると、（S、G）が参加開始しなければならない、および（*、G）が参加決して。
- Backbone routers (i.e., routers that do not have directly attached hosts) MUST NOT propagate (*,G) joins for group addresses in the SSM address range.
- バックボーンルータ（すなわち、直接接続されたホストを持っていないルータ）が伝播してはいけません（*、G）は、SSMアドレス範囲のグループアドレスの加入します。
- Rendezvous Points (RPs) MUST NOT accept PIM Register messages or (*,G) Join messages in the SSM address range.
- ランデブーポイント（RPは）SSMアドレス範囲内のPIM Registerメッセージまたは（*、G）参加メッセージを受け入れてはいけません。
Note that only a small subset of the full PIM-SM protocol functionality is needed to support the SSM service model. This subset is explicitly documented in [9].
フルPIM-SMプロトコル機能のほんの一部がSSMサービスモデルをサポートするために必要であることに注意してください。このサブセットは、明示的に[9]に記載されています。
Interoperability with ASM is one of the most important issues in moving to SSM deployment, since both models are expected to be used at least in the foreseeable future. SSM is the ONLY service model for the SSM address range - the correct protocol behaviour for this range is specified in [5]. The ASM service model will be offered for the non-SSM address range, where receivers can issue (*,G) join requests to receive multicast data. A receiver is also allowed to issue an (S,G) join request in the non-SSM address range; however, in that case there is no guarantee that it will receive service according to the SSM model.
両モデルは、少なくとも予見可能な将来において使用されることが予想されているので、ASMとの相互運用性は、SSMの展開への移行の中で最も重要な課題の一つです。 SSMは、SSMアドレス範囲のための唯一のサービスモデルである - この範囲の正しいプロトコル動作が[5]で指定されています。 ASMサービスモデルは、受信機が発行できる非SSMアドレス範囲、（*、G）のために提供されるマルチキャストデータを受信する要求に参加します。受信機はまた、（S、G）は、非SSMアドレス範囲内に参加要求を発行することを許可されています。ただし、その場合には、それはSSMモデルに応じたサービスを受けるという保証はありません。
Another interoperability issue concerns the MSDP protocol, which is used between PIM-SM rendezvous points (RPs) to discover multicast sources across multiple domains. MSDP is not needed for SSM, but is needed if ASM is supported. [9] specifies operational recommendations to help ensure that MSDP does not interfere with the ability of a network to support the SSM service model. Specifically, [9] states that RPs must not accept, originate or forward MSDP SA messages for the SSM address range.
別の相互運用性の問題は、複数のドメイン間マルチキャストソースを発見するPIM-SMランデブーポイント（RPS）との間で使用されるMSDPプロトコルにも関します。 MSDPは、SSMのために必要されていませんが、ASMがサポートされている場合に必要とされます。 [9] MSDPがSSMサービスモデルをサポートするためのネットワークの能力に干渉しないことを確実にするために、動作推奨を指定します。具体的には、[9] RPは、受け入れる発信またはSSMアドレス範囲のためのMSDP SAメッセージを転送してはならないと述べています。
SSM does not introduce new security considerations for IP multicast. It can help in preventing denial-of-service attacks resulting from unwanted sources transmitting data to a multicast channel (S, G). However no guarantee is provided.
SSMは、IPマルチキャストのための新しいセキュリティの考慮事項を導入しません。これは、マルチキャストチャネル（S、G）にデータを送信する不要なソースから得られたサービス拒否攻撃を防ぐのに役立つことができます。しかし、保証は提供されていません。
We would like to thank Gene Bowen, Ed Kress, Bryan Lyles, Timothy Roscoe, Hugh Holbrook, Isidor Kouvelas, Tony Speakman and Nidhi Bhaskar for participating in lengthy discussions and design work on SSM, and providing feedback on this document. Thanks are also due to Mujahid Khan, Ted Seely, Tom Pusateri, Bill Fenner, Kevin Almeroth, Brian Levine, Brad Cain, Hugh LaMaster and Pekka Savola for their valuable insights and continuing support.
私たちは、SSMに長い議論し、設計作業に参加し、このドキュメントに関するフィードバックを提供するための遺伝子ボーエン、エド・クレス、ブライアンLyles、ティモシー・ロスコー、ヒュー・ホルブルック、イジドールKouvelas、トニー・スピークマンとNidhi Bhaskarに感謝したいと思います。おかげで貴重な洞察力と継続的な支援のためにもムジャヒディン・カーン、テッド・シーリー、トムPusateri、ビルフェナー、ケビンAlmeroth、ブライアン・レヴァイン、ブラッドカイン、ヒューLaMasterとペッカSavolaに起因するものです。
[1] Holbrook, H. and D.R. Cheriton, "IP Multicast Channels: EXPRESS Support for Large-scale Single-Source Applications", In Proceedings of SIGCOMM 1999.
[1]ホルブルック、H.およびD.R. SIGCOMM 1999の議事録では、：Cheriton、「大規模なシングルソース・アプリケーション向けEXPRESSサポートIPマルチキャストチャネル」。
[2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[2]フェナー、W.、 "インターネットグループ管理プロトコル、バージョン2"、RFC 2236、1997年11月。
[3] Cain, B., Deering, S., Kouvelas, I. and A. Thyagarajan, "Internet Group Management Protocol, Version 3.", RFC 3376, October 2002.
[3]カイン、B.、デアリング、S.、Kouvelas、I.およびA. Thyagarajan、 "インターネットグループ管理プロトコル、バージョン3"、RFC 3376、2002年10月。
[4] Holbrook, H. and B. Cain, "Using IGMPv3 and MLDv2 for Source-Specific Multicast", Work In Progress.
[4]「ソース固有マルチキャストのためのIGMPv3およびMLDv2のの使用」ホルブルック、H.およびB.カイン、進行中の作業。
[5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work in Progress.
[5]ホルブルック、H.、およびB.カイン、「ソース固有IPマルチキャストのために」が進行中で働いています。
[6] Deering, S. and D. Cheriton,"Multicast Routing in Datagram Networks and Extended LANs", ACM Transactions on Computer Systems, 8(2):85-110, May 1990.
[6]デアリング、S.とD. Cheriton、 "マルチキャストデータグラムネットワークにおけるルーティングと拡張のLAN"、コンピュータシステム上のACM取引、8（2）：85〜110、1990年5月。
[7] Deering, S. et al., "PIM Architecture for Wide-Area Multicast Routing", IEEE/ACM Transaction on Networking, pages 153-162, April 1996.
[7]デアリング、S.ら、ネットワーク上のIEEE / ACMトランザクション、ページ153-162、1996年4月 "広域マルチキャストルーティングのためのPIMアーキテクチャ"。
[8] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L. Wei, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[8] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL.魏、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2362、1998年6月。
[9] Fenner, B., Handley, M., Holbrook, H. and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", Work In Progress.
[9]フェナー、B.、ハンドレー、M.、ホルブルック、H.及びI. Kouvelas、 "プロトコルの独立してマルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、進行中の作業。
[10] Adams, A., Nicholas, J. and W. Siadek, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", Work In Progress.
[10]アダムス、A.、ニコラス、J.およびW. Siadek、 "プロトコル独立マルチキャスト - デンスモード（PIM-DM）：プロトコル仕様（改訂）"、進行中の作業。
[11] Ballardie, A., "Core-Based Trees (CBT) Multicast Routing Architecture", RFC 2201, September 1997.
[11] Ballardie、A.、 "コアベースツリー（CBT）マルチキャストルーティングアーキテクチャ"、RFC 2201、1997年9月。
[12] Meyer, D., "Adminstratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[12]マイヤー、D.、 "AdminstrativelyスコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[13] Farinacci, D. et al., "Multicast Source Discovery Protocol", Work In Progress.
[13]ファリナッチ、D.ら、「マルチキャスト発信元ディスカバリプロトコル」、進行中の作業。
[14] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[14]ターラー、D.、ハンドリー、M.とD. Estrin、 "インターネットマルチキャストアドレス配分アーキテクチャ"、RFC 2908、2000年9月。
[15] Diot, C., Levine, B., Lyles, B., Kassem, H. and D. Balensiefen, "Deployment Issues for the IP Multicast Service and Architecture", In IEEE Networks Magazine's Special Issue on Multicast, January, 2000.
[15] Diot、C.、レヴァイン、B.、Lyles、B.、Kassem、H.およびD. Balensiefen、マルチキャスト上のIEEEネットワークマガジンの特集では、 "デプロイの問題IPマルチキャストサービスと建築のための" 1月、 2000。
[16] Thaler, D., Fenner B. and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", Work in Progress.
[16]ターラー、D.、フェナーB.およびB.クイン、「マルチキャストソースフィルタのためのソケットインタフェース拡張」が進行中で働いています。
[17] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[17]マイヤー、D.およびP. Lothberg、 "8分の233にアドレッシングGLOP"、BCP 53、RFC 3180、2001年9月。
[18] Levine, B. et al., "Consideration of Receiver Interest for IP Multicast Delivery", In Proceedings of IEEE Infocom, March 2000.
[18]レヴァイン、B.ら、「IPマルチキャスト配信のためのレシーバ利益の検討」、IEEEインフォコム、2000年3月の議事録。
[19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery for IPv6", RFC 2710, October 1999.
[19]デアリング、S.、フェナー、W.およびB.ハーバーマン、 "IPv6のマルチキャストリスナ発見"、RFC 2710、1999年10月。
[20] Vida, R. et. al., "Multicast Listener Discovery Version 2(MLDv2) for IPv6", Work In Progress.
[20]ヴィダ、R.ら。ら、「IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）」、進行中の作業。
[21] Haberman, B. and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast Addresses", RFC 3306, August 1992.
[21]ハーバーマン、B.およびD.ターレル、 "ユニキャストプレフィックスベースのIPv6マルチキャストアドレス"、RFC 3306、1992年8月。
[22] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[22]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[23] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[23]ハーバーマン、B.、 "IPv6マルチキャストアドレスの割り当てに関するガイドライン"、RFC 3307、2002年8月。
[24] Ballardie, A., "Core-Based Trees (CBT Version 2) Multicast Routing -- Protocol Specification", RFC 2189, September 2001.
[24] Ballardie、A.、 "コアベースツリー（CBTバージョン2）マルチキャストルーティング - プロトコル仕様"、RFC 2189、2001年9月。
[25] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC 1112, August 1989.
[25]デアリング、S.、 "IPマルチキャスティングのためのホスト拡大"、STD 5、RFC 1112、1989年8月。
[26] Bates, T., Rekhter, Y., Chandra, R. and D. Katz, "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000.
[26]ベイツ、T.、Rekhter、Y.、チャンドラ、R.及びD.カッツ、 "BGP-4のためのマルチプロトコルの拡張"、RFC 2858、2000年6月。
[27] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.
[27]マイヤー、D.、 "8分の233で拡張割り当て"、RFC 3138、2001年6月。
[28] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[28]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
Christophe Diot Intel EMail: christophe.diot@intel.com
クリストフDiotインテル電子メール：christophe.diot@intel.com
Leonard Giuliano Juniper Networks EMail: lenny@juniper.net
レオナルドジュリアーノジュニパーネットワークスのEメール：lenny@juniper.net
Greg Shepherd Procket Networks EMail: shep@procket.com
グレッグ・シェパードProcket NetworksのEメール：shep@procket.com
Robert Rockell Sprint EMail: rrockell@sprint.net
ロバートロッケルスプリントメールアドレス：rrockell@sprint.net
David Meyer Sprint EMail: dmm@1-4-5.net
デビッド・マイヤースプリントメールアドレス：dmm@1-4-5.net
John Meylor Cisco Systems EMail: jmeylor@cisco.com
ジョンMeylorシスコシステムズ電子メール：jmeylor@cisco.com
Brian Haberman Caspian Networks EMail: bkhabs@nc.rr.com
ブライアンハーバーマンカスピアン・ネットワークEメール：bkhabs@nc.rr.com
Supratik Bhattacharyya Sprint
Suprtikバッタチャリヤスプリント
EMail: supratik@sprintlabs.com
メールアドレス：supratik@sprintlabs.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。