[要約] RFC 3569は、ソース固有マルチキャスト（SSM）の概要を提供するものであり、SSMの目的は、マルチキャストトラフィックの効率的な配信とセキュリティを向上させることです。
Network Working Group S. Bhattacharyya, Ed.
Request for Comments: 3569 Sprint
Category: Informational July 2003
An Overview of Source-Specific Multicast (SSM)
ソース固有のマルチキャスト（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.
Copyright（c）The Internet Society（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サービスモデルが、ドメイン間のマルチキャスト展開で直面する課題、ルーティングプロトコルとアプリケーションに必要な変更にどのように対処するかについて説明します。
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.
このドキュメントは、ソース固有のマルチキャスト（SSM）サービスと、PIM-SMおよびIGMP/MLDプロトコルを使用した展開の概要を提供します。SSMが提供するネットワークレイヤーサービスは、SSM宛先IPアドレス（G）とソースIPアドレスSによって識別される「チャネル」です。IPv4アドレス範囲は、SSMサービスで使用するためにIANAによって予約されています。IPv6には、SSM宛先アドレスの範囲がすでに存在します。ソースSは、IPデータグラムをSSM宛先アドレスGに送信します。レシーバーは、チャネル（ソース、グループ）または（s、g）を購読することにより、これらのデータグラムを受信できます。チャネルサブスクリプションは、IPv4のIGMPプロトコルのバージョン3およびIPv6のMLDプロトコルのバージョン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].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" should "、" nove "、" becommended "、" may "、および" optional "があります。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.
Any-Source Multicast（ASM）：これは、RFC 1112 [25]で定義されているIPマルチキャストサービスモデルです。IPデータグラムは、単一のIP宛先アドレス（IPv4の場合は224.0.0.0.0〜239.255.255.255）によって識別されるゼロ以上のエンドホスト（またはルーター）のセットである「ホストグループ」に送信されます。エンドホストはいつでもグループを離れることができ、その場所や数に制限はありません。さらに、このモデルは、任意の多くの送信者を持つマルチキャストグループをサポートしています。エンドホスト（またはルーター）は、そのグループのメンバーではない場合でも、ホストグループに送信できます。
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データグラムは、ソースSによってSSM宛先アドレスGに送信され、レシーバーはチャネル（S、G）を購読することによりこのデータグラムを受信できます。SSMはホストアプリケーションに「チャネル」抽象化を提供します。各チャネルには、正確に1つのソースと任意の数のレシーバーがあります。SSMは、Express [1]の以前の研究から派生しています。アドレス範囲232/8は、IANAによってIPv4のSSMサービスのために割り当てられています。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.0-239.255.255.255）。次のようにASMサービスモデルを拡張します。各「上層層プロトコルモジュール」は、特定のソースセットのみでホストグループGに送信されたデータを要求したり、特定のソースを除くすべてのセットからホストグループGに送信されたデータを要求することができます。ソースフィルタリングのサポートは、IPv4用のインターネットグループ管理プロトコル（またはIGMPV3）[3]のバージョン3、およびMulticastリスナーディスカバリー（またはMLDV2）[22] IPv6のプロトコルのバージョン2によって提供されます。今後、これら2つのプロトコルを「SFM対応」と呼びます。これらのプロトコルの以前のバージョン-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.
このドキュメントの目的のために、[12]のスコープされたマルチキャストモデルをASMのバリアントであると扱います。これは、ソースの数を明示的に制限していないが、グループのスコープゾーン内に配置する必要があるためだけです。
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をサポートするための最も一般的なマルチキャストプロトコルスイートの1つは、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.
PIM-DM [10]、CBT [24,11]、DVMRP [6]などの多くのプロトコルは、同じ管理ドメインのすべての受信機とソースの間にマルチキャストツリーを構築するために存在しますが、PIM-SM [8、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は、MSDPプロトコルを使用して、他のドメインのRPSにマルチキャストソースを発表します。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サービスモデルによってもたらされるコア展開の課題の1つです。現在のマルチキャストアーキテクチャは、複数のアプリケーション間の住所衝突を防ぐための展開可能なソリューションを提供しません。マルチキャストアドレススペースのサイズがはるかに大きいため、問題はIPv4よりもはるかに深刻ではありません。静的アドレス割り当てスキームであるGLOP [17]は、IPv4の暫定ソリューションとして提案されています。ただし、GLOPアドレスは登録されたASごとに割り当てられます。これは、ソースの数がマッピングに使用できるAS数を超える場合には不十分です。RFC 3138はRFC 2770を拡張して、ルーティングレジストリがRFC 1930プライベートに対応するGLOPスペースからマルチキャストアドレスをスペースとして割り当てることを可能にします[27]。このスペースは、エグロップ（拡張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）ペアで識別される「チャネル」を定義します。ここで、Sはソースアドレスであり、GはSSM宛先アドレスです。チャネルサブスクリプションは、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、g）はチャネル（S2、g）とは異なり、S1とS2はソースアドレスであり、GはSSM宛先アドレスです。。これにより、SSM宛先アドレスのグローバル割り当ての問題が回避され、各ソースが作成するさまざまなチャネルのアドレス衝突を解決するために独立して責任を負います。
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機能を確保するために、ルーターがチャネルを持たないネットワークの一部にSSMトラフィックを送信してはならないことを推奨する運用ポリシーが提案されています[9]加入者。
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は、232/8の範囲のみに結合する（S、G）を制限しないことに注意してください。ただし、[5]で定義されているSSMサービスは、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の両方を知っている必要があります。チャネル発見はアプリケーションの責任です。この情報は、Webページ、セッションアナウンスアプリケーションなどを含むさまざまな方法で利用できます。これは、潜在的なサブスクライバーがマルチキャストを知ることができるように、マルチキャストセッションを発表する必要があるASMアプリケーションに使用されるものに似ています。実際、グループアドレス、エンコードスキームなど。発表する必要がある追加の情報唯一の情報は、宣伝されているチャネルのソースアドレスです。ただし、これを行うための正確なメカニズムは、このフレームワークドキュメントの範囲外です。
There are two main issues in making multicast applications "SSM-aware":
マルチキャストアプリケーションを「SSM-Aware」にすることには、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ルーターが使用するマルチキャストリスナーディスカバリー（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スタイルの動作の防止に関係しています。[5]に従って[9]で説明されているように、[5] PIM-SMプロトコルのいくつかの変更が必要です。[5]へのコンプライアンスに必要なPIM-SMの最も重要な変更は、次のとおりです。
- 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がSSMアドレス範囲のアドレスGで（s、g）結合リクエストを受信した場合、a（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.
- バックボーンルーター（つまり、ホストが直接接続されていないルーター）は、SSMアドレス範囲のグループアドレスのために結合してはなりません（*、g）。
- Rendezvous Points (RPs) MUST NOT accept PIM Register messages or (*,G) Join messages in the SSM address range.
- Rendezvous Points（RPS）は、PIMレジスタメッセージを受け入れたり、（*、g）SSMアドレス範囲にメッセージを結合してはなりません。
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].
SSMサービスモデルをサポートするには、完全なPIM-SMプロトコル機能の小さなサブセットのみが必要であることに注意してください。このサブセットは[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展開に移行する上で最も重要な問題の1つです。これは、両方のモデルが少なくとも予見可能な将来に使用されると予想されるためです。SSMは、SSMアドレス範囲の唯一のサービスモデルです。この範囲の正しいプロトコル動作は[5]で指定されています。ASMサービスモデルは、レシーバーがマルチキャストデータを受信するためにリクエストを発行できる（*、g）発行できる非SSMアドレス範囲に提供されます。レシーバーは、非SSMアドレス範囲に（s、g）結合要求を発行することも許可されています。ただし、その場合、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.
別の相互運用性の問題は、MSDPプロトコルに関係しています。MSDPプロトコルは、PIM-SMランデブーポイント（RPS）間で使用され、複数のドメインにわたってマルチキャストソースを発見します。SSMにはMSDPは必要ありませんが、ASMがサポートされている場合は必要です。[9] MSDPがSSMサービスモデルをサポートするネットワークの能力を妨げないようにするための運用上の推奨事項を指定します。具体的には、[9]は、RPSが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に関する長い議論とデザイン作業に参加し、この文書に関するフィードバックを提供してくれたことに感謝します。また、Mujahid Khan、Ted Seely、Tom Pusateri、Bill Fenner、Kevin Almeroth、Brian Levine、Brad Cain、Hugh Lamaster、Pekka 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.Cheriton、「IPマルチキャストチャネル：大規模なシングルソースアプリケーションのサポートを表明」、1999年のSigcommの議事録。
[2] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997.
[2] Fenner、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] Cain、B.、Deering、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] Holbrook、H。およびB. Cain、「ソース固有のマルチキャストにIgmpv3とMLDV2を使用する」、進行中の作業。
[5] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", Work in Progress.
[5] Holbrook、H。およびB. Cain、「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] Deering、S。and D. Cheriton、「データグラムネットワークと拡張LANSのマルチキャストルーティング」、コンピューターシステムの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] Deering、S。et al。、「幅広いマルチキャストルーティングのためのPIMアーキテクチャ」、NetworkingのIEEE/ACMトランザクション、1996年4月153〜162ページ。
[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.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P。and L. wei、 "プロトコル独立マルチキャスト - スパースモード（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] Fenner、B.、Handley、M.、Holbrook、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] Adams、A.、Nicholas、J。and 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] Meyer、D。、「接点がスコープされたIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。
[13] Farinacci, D. et al., "Multicast Source Discovery Protocol", Work In Progress.
[13] Farinacci、D。et al。、「マルチキャストソースディスカバリープロトコル」、進行中の作業。
[14] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.
[14] Thaler、D.、Handley、M。and D. Estrin、「The Internet Multicast Address Arlocation Architecture」、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.、Levine、B.、Lyles、B.、Kassem、H。、およびD. Balensiefen、「IPマルチキャストサービスとアーキテクチャの展開の問題」、IEEE Networks MagazineのMulticastの特別号、2000年1月。
[16] Thaler, D., Fenner B. and B. Quinn, "Socket Interface Extensions for Multicast Source Filters", Work in Progress.
[16] Thaler、D.、Fenner B.およびB. Quinn、「マルチキャストソースフィルター用のソケットインターフェイス拡張機能」、進行中の作業。
[17] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", BCP 53, RFC 3180, September 2001.
[17] Meyer、D。およびP. Lothberg、「233/8の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] Levine、B。et al。、「IPマルチキャスト配信に対する受信者の関心の考慮」、IEEE Infocomの議事録、2000年3月。
[19] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery for IPv6", RFC 2710, October 1999.
[19] Deering、S.、Fenner、W。and B. Haberman、「IPv6のマルチキャストリスナーディスカバリー」、RFC 2710、1999年10月。
[20] Vida, R. et. al., "Multicast Listener Discovery Version 2(MLDv2) for IPv6", Work In Progress.
[20] Vida、R。et。al。、「IPv6用のマルチキャストリスナーディスカバリーバージョン2（MLDV2）」、進行中の作業。
[21] Haberman, B. and D. Thaler, "Unicast-Prefix-Based IPv6 Multicast Addresses", RFC 3306, August 1992.
[21] Haberman、B。およびD. Thaler、「Unicast-PrefixベースのIPv6マルチキャストアドレス」、RFC 3306、1992年8月。
[22] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[22] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[23] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, August 2002.
[23] Haberman、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] Deering、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] Bates、T.、Rekhter、Y.、Chandra、R。、およびD. Katz、「BGP-4のマルチプロトコル拡張」、RFC 2858、2000年6月。
[27] Meyer, D., "Extended Assignments in 233/8", RFC 3138, June 2001.
[27] Meyer、D。、「233/8の拡張課題」、RFC 3138、2001年6月。
[28] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[28] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
Christophe Diot Intel EMail: christophe.diot@intel.com
Christophe Diot Intel Email：christophe.diot@intel.com
Leonard Giuliano Juniper Networks EMail: lenny@juniper.net
Leonard Giuliano Juniper Networksメール：lenny@juniper.net
Greg Shepherd Procket Networks EMail: shep@procket.com
Greg Shepherd Procket Networks Email：shep@procket.com
Robert Rockell Sprint EMail: rrockell@sprint.net
Robert Rockell Sprintメール：rrockell@sprint.net
David Meyer Sprint EMail: dmm@1-4-5.net
David Meyer Sprintメール：dmm@1-4-5.net
John Meylor Cisco Systems EMail: jmeylor@cisco.com
John Meylor Cisco Systems Email：jmeylor@cisco.com
Brian Haberman Caspian Networks EMail: bkhabs@nc.rr.com
Brian Haberman Caspian Networksメール：bkhabs@nc.rr.com
Supratik Bhattacharyya Sprint
Supratik Bhattacharyya Sprint
EMail: supratik@sprintlabs.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。